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
Jerry Avins wrote: > Rune Allnor wrote: > > ... > > > > through before taking any actions. It's the antithesis to the "make > > code now!" approach I have very poor experiences with. > > > > There are usually several ways to get something done, one is usually > > more favourable than others. This may depend on the actual > > circumstances > > of the project. "Design" is about analysing the problem and selecting > > how to do things. It could be all those talks with the customer before > > the project actually takes place, or it could be the coder deciding > > whether to implement some function as a recursive call or some nested > > loop. > > Either one might get the job done right now, but "the big picture" > > might > > suggest that some task or extension becomes easier in the future, > > should particular method be chosen over the other. > > I've thrown out a lot of early code because it led to unfortunate data > structures or module interfaces. I'm not prescient enough to get those > right most of the time on unfamiliar ground, and I know it. Same as me, then. That's why I am so obstinate about "design", about getting it right. If not "first time", so "some time". "Early" would be preferable. > My approach > is to write a quickie that covers most of the ground, try to use it, and > learn a better way from it. It would be a waste to give it more features > that what's needed for a shakedown, then I chuck it and start over. Many > programmers I admire work that way.* Sure. The problem is, as you indicate, when one does not discriminate between an initial prototype and the finished product. > Sometimes, I just do that in my head. I've actually debugged assembly > code by single-stepping it in my head as I drove home from work. I > suppose I should have been elated at finding my bug, but it made me feel > pretty stupid. Must of the bugs I've found, were typos or other blunders that made me look plain stupid. There were one or two, though, I learned a lot from. Here is one that took me a month to find. I only understood there was a problem after I ported the code from one system to another. /** C code *************************************************/ float a; float *p; int i; /* initialize p as an array containing N > i floats */ a =3D *p[i]; /***********************************************************/ > Throwing code away can be depressing if it was originally intended to be > kept, but making it part of the planning process takes the sting out. Now we are talking. "Making it part of the planning process." > Has there ever been a completed project that couldn't be improved by > another go-round? A quickie prototype can capture most of the benefit of > a second chance. Or it might screw the whole thing up, what subsequent extensions are concerned. Rune > Jerry > _________________________________ > * If the boss will insist that you flesh it out and keep it, do it in > secret. At home on your own time if need be. > -- > Engineering is the art of making what you want from things you can get. > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AFArticle: 87576
Hello, The pulse is 40 ns wide.... Thank you everybody.... MethiArticle: 87577
I wrote a task to feed test vectors to my design, however, I realized some differences between "task" and the normal state machines I used to do. One sample code below, I am expecting the the signal "trd_sample" to be delayed by one cycle of "trc", i.e. 2nd posedge of trc. However, why does the simulation shows on the first posedge of trc? I have put the modelsim waveform here. http://img234.imageshack.us/img234/5034/confusedtask7bg.jpg Thank you in advance. module sim; reg clk; reg rst_n; reg trw; reg [3:0] trd; reg trc; reg [3:0] trd_sample; always #5 clk <= ~ clk; initial begin clk <= 1'b0; rst_n <= 1'b1; #1 rst_n <= 1'b0; #2 rst_n <= 1'b1; tx_in; $stop(); end task tx_in; integer i, j; begin @ (posedge clk); @ (posedge clk); trc <= 1'b0; trw <= 1'b0; trd <= 4'h0; @ (posedge clk); trc <= 1'b1; trw <= 1'b1; trd <= 4'hA; @ (posedge clk); trc <= 1'b0; @ (posedge clk); trc <= 1'b1; trd <= 4'h9; @ (posedge clk); trc <= 1'b0; @ (posedge clk); trc <= 1'b1; trd <= 4'h8; @ (posedge clk); trc <= 1'b0; @ (posedge clk); trc <= 1'b1; trd <= 4'h7; @ (posedge clk); @ (posedge clk); @ (posedge clk); @ (posedge clk); end endtask always @ (posedge trc or negedge rst_n) begin if (~rst_n) trd_sample <= 4'h0; else begin if (trw) trd_sample <= trd; end end endmoduleArticle: 87578
Hi all ! I would like to make a Spartan 3 FPGA to reset and reprogram itself from a platform prom after I have reprogrammed the prom using JTAG boundery-scan. Is there any instruction I can send to the FPGA or the prom with JTAG to tell the FPGA to reprogram ? Usually this is done at power-on, but in my case, I can't power-off/on the whole system to make the FPGA to get a new firmware, and I can't reprogram the FPGA directly because it's required for the JTAG operation. Thank you UxelloArticle: 87579
"uxello" <uxello@free.fr> schrieb im Newsbeitrag news:42e64094$0$20177$626a14ce@news.free.fr... > Hi all ! > > > I would like to make a Spartan 3 FPGA to reset and > reprogram itself from a platform prom after I have > reprogrammed the prom using JTAG boundery-scan. > > Is there any instruction I can send to the FPGA > or the prom with JTAG to tell the FPGA to reprogram ? > Usually this is done at power-on, but in my case, > I can't power-off/on the whole system to make the > FPGA to get a new firmware, and I can't reprogram > the FPGA directly because it's required for the > JTAG operation. > > Thank you > > > Uxello you can send 'config' command to the platform flash over JTAG if you back-connect the JTAG to the FPGA or you may pull PROG_B low, in both cases the reconfig would restart. We are doing similar thing where FPGA contains PCI logic and JTAG port to its own platform flash. So the platform flash is reprogrammed from JTAG interface that is in the FPGA and then same FPGA is reconfigured with new bitstream. unfortunatly we are using XCF08P and xilinx has some issues with it, so we can reprogram the XCF08P but FPGA is not getting configured. We have opened 4 or 5 WebCases on this matter but not getting much help. The first WebCase we opened - the response from Xilixn was: - well there has been not much interest in XCFxxP IEEE1532 BSDL files, so we have not made them. They are scheduled for 2006. You have to wait. I assume you are using XCFxxS so hopefully you are doing better with it, to my knowledge there are less or no problems with XCFxxS JTAG Commands to force fpga load for XCFxxS CONFIG (11101110) XCFxxP XSC_CONFIG (0000000011101110) always look at the BSDL files in Xilinx\xcfp\data\ !! AnttiArticle: 87580
Teo wrote: > Just saw that Lattice announced a free open source 8 bit micro on their > site. > > http://www.latticesemi.com/products/devtools/ip/refdesigns/mico8.cfm > > Any code wizards out there who can write a C compilier for this mico8? > This open core would sure make life easier than dealing with the lawyer > documents needed for an IP core. > > Teo > you probably know that there are numerous other free vhdl micro models, particularly a PIC 16C5x. This one is nice because Microchip provides a free developpement tool for PIC's micros. You can get the PIC 16C5x vhdl there: http://tech-www.informatik.uni-hamburg.de/vhdl/ And the PIC dev-tool (MPLAB) there: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 UxelloArticle: 87581
> JTAG Commands to force fpga load for > XCFxxS > CONFIG (11101110) > XCFxxP > XSC_CONFIG (0000000011101110) > Thank you Antti, I've also found that I could also check the "Load FPGA" option when I was generating the xsvf file. That's even easier for me since i'm using XSVF player (XAPP058). UxelloArticle: 87582
Hello, i'm using XPS to build a system based on a Microblaze cpu, and i would like to add a Chipscope OPB IBA to analyse OPB . I connect it through my mb_opb but i've got this error NgdBuild:455 - logical net 'ilmb_LMB_BE<0>' has multiple driver(s): pin G on block XST_GND with type GND, pin O on block chipscope_opb_iba_0/chipscope_opb_iba_0/i_chipscope_opb_iba_0/chipscope_opb_i ba_0/i_no_d/u_ila/u_dout with type LUT3 does anyone know why my chipscope is driving a LMB net although i just want to connect it to OPB bus thanks in advance cedric.Article: 87583
<bazogec@hotmail.com> schrieb im Newsbeitrag news:1122388791.828073.303630@g43g2000cwa.googlegroups.com... > Hello, i'm using XPS to build a system based on a Microblaze cpu, and i > would like to add a Chipscope OPB IBA to analyse OPB . I connect it > through my mb_opb but i've got this error > > NgdBuild:455 - logical net 'ilmb_LMB_BE<0>' has multiple driver(s): > pin G on block XST_GND with type GND, > pin O on block > chipscope_opb_iba_0/chipscope_opb_iba_0/i_chipscope_opb_iba_0/chipscope_opb_ i > ba_0/i_no_d/u_ila/u_dout with type LUT3 > > does anyone know why my chipscope is driving a LMB net although i just > want to connect it to OPB bus > > thanks in advance > cedric. > its not driving LMB bus actually - there is mockup with the chipscope cores, so 2 signals from unrelated modules that both are logic ground are seen as being connected together and that makes the tools think there is multiply driver conflict. this problem happens sometimes. im not sure how to avoid this. AnttiArticle: 87584
It seems to me that much of this discussion is tempered by the size of the organization that each participant is involved in. For virtually all my career, I have worked (and had ownership in) small companies. I think this case, the marketing & engineering aspects of the projects tend to be more naturally coupled together and management is not likely to be pointy haired. In most of my larger projects (which for me might involve 4-5 people), we usually had a fairly good vision of what we wanted to accomplish when we started, but at the same time, we never over specified a project from the start. Nevertheless, we rarely built lots of small incremental prototypes, it takes too long. We used kind of a successive approximation method that was drove to the production version as soon as possible. Sure, we might have prototyped small segments as needed. In most projects, the collective talent already knows how to do 80 - 90% of the project before it even starts (or knows where the answers lie). Dotting every i and crossing every t, is very slow. You also tend to create a number of very good useless pieces that you discard anyway. If the project takes too long, the solution may no longer be relevant. I think the key to the successful projects, that I worked on was that everyone understood the basic vision, and there was always a architect on the project that understood the broader issues. You can always find a better way of solving a problem the next time. Sometimes, its because you learned something from the previous project, sometimes its new components (like a new DSP chip), sometimes its economics, etc. One of the challenges for the project leader (who in our case was usually the architect), was to access when to change course in the middle of a project and when to stay the course (and sometimes shoot the engineers). I have killed projects in the middle and almost completely started over. This is painful, but usually, the next attempt is a lot better. Probably, the most successful project I was involved in started with a well defined goal, that had 2.5 months to bring from idea to production (including deliverable products). The timing was forced by a trade show. We designed everything as a production solution (extruded housings, injection molded bezels, custom circuit boards, firmware, etc). We didn't even start the firmware until the last week before the tradeshow. This was actually part of the plan since timing was everything. The team consisted of 5 people. Suffice to say, we were the most successful exhibitor at the tradeshow. We had people standing three deep into the exhibit floor most of the show. After about a year, we had captured about 80% of our market (we had two competitors when we launched our product at the tradeshow). If we had followed the build a little, test, build a little more, we would not have succeeded since time to market would have let the opportunity slip away. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com "Peter K." <p.kootsookos@iolfree.ie> wrote in news:1122341607.028547.67040@g49g2000cwa.googlegroups.com: > Randy Yates wrote: > >> I'm not familiar with the spiral/agile model, but you'll have to >> do some pretty fancy talking to convince me to agree that something >> other than a strict development cycle flow is going to produce a >> better system in the long run. > > Oh, it's still a strict development cycle... if anything, it's more > strict than the big design up front. It just panders a little better > to customers and, in my experience, handles changing requirements much > better. > >> The problem I've seen is that, in the process of stumbling over one's >> feet to get _something_ out that works, that the managers can >> touchie-feelie-see, one ends up skimping or dumbing down the high >> level design. > > Not at all. You don't dumb down the design, you just instantiate > those parts of it that are clearest first. > >> Then, when that happens, the remainder of the project's >> development is crippled, with the end result either that it took MORE >> time than it would have taken had a proper high level design been >> performed, or that the performance/maintainability/extendability of >> the system is greatly comprimised. > > It depends on what you mean by "proper high level design" --- don't > get me wrong, there is still abstract, forward-leaning thought > involved. It's just that most designs I've seen try to get too stuck > into details too early. > >> > Big up-front design can be a killer when requirements change. For >> > some reason, managers and customers seem to think that software can >> > be changed much more easily than mechanical systems... so they do. >> > The trick is to figure out when they're really expressing a new >> > requirement, or just jumping on the latest Big Thing. >> >> You can't have your cake and eat it too. Either take a hit sticking >> to your requirements, or dumb-down your system. > > Actually, you can. That's part of the point of the spiral / agile > methods: allow some flux in requirements (it will always be there), > but don't make dumb decisions about it. > > Ciao, > > Peter K. >Article: 87585
Mike, Try reading XST constraints guide and also XST user's guide. There is a very nice explanation of this stuff. Concerning the problems in your timing analysis, try pipelining your design and use timing-driven packing. But if you can paste a few timing violations here, we can help understanding them. Vladislav "mike" <lnadjwa@yahoo.com> wrote in message news:1122375171.254551.289020@g14g2000cwa.googlegroups.com... > Hi, > > I want to understand the basic path types as: clock t osetu; clock to > pad because i have many problems when i made the static timing after > place and route ( xst tool of xilinx) and also the timing > verification....thanks a lot >Article: 87586
+HI, Is it possible to create a comparator structure that has a priority structure eg My system has more than 65% cases where the winner is determined by the msb(matlab simulations).I am trying to create an asynchronous system, so early completion would be beneficial for my system. Essenatially i need a completion detection comparator. THanks VishArticle: 87587
methi wrote: > Hello, > > The pulse is 40 ns wide.... I asked, "how wide is the pulse. In number of clock ticks." How many clock cycles is 40 ns? The actual number in units of time is meaningless. -aArticle: 87588
Hi guys,
Has anyone tried instantiating IOBUF in a Spartan-3E device? The IOBUF
primitive for S3E has two new attributes namely IBUF_DELAY_VALUE and
IFD_DELAY_VALUE:
IOBUF_inst : IOBUF
generic map (
DRIVE => 12,
IBUF_DELAY_VALUE => "0",
IFD_DELAY_VALUE => "AUTO",
IOSTANDARD => "DEFAULT",
SLEW => "SLOW")
port map (
O => output,
IO => input_output,
I => input,
T => enable
);
These two new attributes don't seem to be recognised by PAR, since
translate generates these warnings:
WARNING:NgdBuild:486 - Attribute "IBUF_DELAY_VALUE" is not allowed on
symbol
"IOBUF_inst" of type "IOBUF". This attribute will be ignored.
WARNING:NgdBuild:486 - Attribute "IFD_DELAY_VALUE" is not allowed on
symbol
"IOBUF_inst" of type "IOBUF". This attribute will be ignored.
Thus, signals don't get routed. I am using ISE 7.1.03 which as far as I
am aware is the latest release. Any ideas what is wrong?
Best regards
George
Article: 87589Hey, I just got a board with a virtex4 and there is a LVDS connection on it and another LVDS input bank where the clock oscillators are connected to. that bank is a Vcco=3.3V bank but has a 2.5V LVDS connection, but since http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&ge tPagePath=16830 says this is not a problem i hope this is not the problem. Now the problem is that when i download the code and boot chipscope analyzer, the analyzer says it does not find any core (although there is a ICON/ILA core in it) and when i check with fpga editor there is indeed a ICON/ILA core. So that is why i thought that the clock generation is a problem (although the clk's are generated since i can see them at the input pad of the fpga)? especially since i cannot get anything out of the fpga, everything remains inactive for some reason... i also get this warning: ARNING:Xst:1474 - Core <vio> was not loaded for <i_vio> as one or more ports did not line up with component declaration. Declared input port <control<35>> was not found in the core. Please make sure that component declaration ports are consistent with the core ports including direction and bus-naming conventions. WARNING:Xst:1474 - Core <ila2> was not loaded for <i_ila2> as one or more ports did not line up with component declaration. Declared input port <control<35>> was not found in the core. Please make sure that component declaration ports are consistent with the core ports including direction and bus-naming conventions. WARNING:Xst:1474 - Core <ila1> was not loaded for <i_ila1> as one or more ports did not line up with component declaration. Declared input port <control<35>> was not found in the core. Please make sure that component declaration ports are consistent with the core ports including direction and bus-naming conventions. WARNING:Xst:1474 - Core <icon> was not loaded for <i_icon> as one or more ports did not line up with component declaration. Declared output port <control0<3>> was not found in the core. Please make sure that component declaration ports are consistent with the core ports including direction and bus-naming conventions. but since i've seen this warning in the past and chipscope worked i don't think this is the problem. I hope some of you know where i can start looking since for now i don't have a clue ... kind regards, YttriumArticle: 87590
Kees van Reeuwijk wrote: > Peter Alfke <alfke@sbcglobal.net> wrote: > > > Austin gave an interesting analogy: > > > Don't let anybody put a ring in your nose... > > Peter Alfke, Xilinx Applications (from home) > > Could you Xilinx people please grow up, this is not insightful, this is > not even zealous company loyalty, this is just boyclub bickering. > > A reasoned discussion about advantages and disadvantages of FPGA > architectures is interesting, but do you really think that this kind of > posting is informative for /anyone/? FWIW, I completely agree with Kees. -aArticle: 87591
Hi, something really strange just happened. I tried to generate a testbench waveform to simulate on modelsim and modelsim comes up with the following error before simulation begins. # ** Error: top_test.vhw(24): near ";": expecting: CHARACTER STRING IDENTIFIER ALL double clicking that opens up the vhdl description of the waveform where one line reads use WORK.ALL.; well that dot should obviously not be there... Any ideas?Article: 87592
Antti Lukats wrote: > "Jedi" <me@aol.com> schrieb im Newsbeitrag > news:i74Fe.125$Sg3.58@read3.inet.fi... > >>Jedi wrote: >> >>>Moro >>> >>>Back from a successful trip in .ch I have to change >>>my contact details at Altera and they provide >>>an email address for doing this: >>> >>> csecom@altera.com >>> >>>which just leads into nirvana and bounces back >>>with "user unknown"... >>> >>>Any other address to use? Or why is it not allowed to >>>change address online? >> >>I guess nobody at Altera discovered this or don't care? >> >> >>rick > > > they dont care > And all Altera guys seem to be on vacation for several weeks now... as well as their webmasternot knowning that csecom@altera.com results in "unknown user"... Looks like I have to fly to Finland from Switzerland every time a new NIOS/Quartus upgarde is out (o; rickArticle: 87593
"hata" <sabatian@libero.it> schrieb im Newsbeitrag news:1122377144.005204.205540@g47g2000cwa.googlegroups.com... > Hi all, > > I am looking for information about licensing of HW designs. To be more > specific I would like to find out what kind of license comes with the > WishBone specification (rev B.3). I read on the OpenCores web site that > they refer to the GPL licence but after having read it on > http://www.gnu.org I have a lot of questions. It is not clear to me > once a GPL licensed softcore is included in a larger design then the > whole design MUST be made available under the same conditions of the > GPL core. Moreover on the OpenCore web site > (http://opencores.nnytech.net/faq.cgi/section/4/4.1#4.1) it is written > that: > > "Conversely, if you use a GPLed item, you MUST distribute all > information about it and NOT prevent others from redistributing or > modifying it. Stating it as an oversimplification: you cannot keep > secrets unless you want your butt sued." > > Does this mean that a company who makes money on the design they make > cannot use free cores because they would be OBLIGED to "distribute all > information about it"? If a design center uses a free IP in their > design, must they make the source code of the whole IC available to > everybody? Or the entire data base? Or none of them? And what if they > design their IPs but all of them are equipped with a WishBone > interface: they do not use any source code but just the WishBone > specifications. Must they publish their source code? > > I've already googled but I was not able to find the information I was > looking for. Suggestion, articles, URLs and anything useful to my > purpose is welcomed. > > Thanks in advance. > > hata > wishbone and compliant products can be for profit without the need to reveal the sources. the licensing must be checked for each case in separate, the GPL is the worst license (most restrictive). in generic, you can use pretty much all you can (open source ipcore stuff) the chances that somebody will actually sue you are very little. Of course if you are trying to sell a ip core in source form that is largely based on the GPL source code than that would not end very well. But if you use open source IP cores in some ASIC without publishing the sources, then nothing happens - because no one will know whats inside the asic and as there is no party that could sue you or has even interest in doing so. sure check it out with some good lawer to makes sure there are no chances you get sued. AnttiArticle: 87594
Antti Lukats wrote: > "arie" <aries@wisair.com> schrieb im Newsbeitrag > news:1122326731.202651.187530@g44g2000cwa.googlegroups.com... > > > > I know the device is not recomended for new designs, i use it for > > prototyping, > > final product will be based on ASIC with ARM core inside. i dont know > > of any other protoyping solution that can offer 200MHZ ARM9 processor + > > fpga. > > > > Arie > > > try STW22000 from ST and forget Altera > ARM926 300MHz + FPGA > > Antti Hello Anttii, I just read the spec of this device, as i understand the PLD section of this device can not be AHB master. This is a requirment on my project since data addresing is done by hardware. Thanks, Arie.Article: 87595
Hello everyone, I am floored by the number of responses to my original post. I want to thank everyone for taking the time to express their thoughts, experiences and opinions. I also want to pass on a document I found on the internet, http://www.guymacon.com/ENGINEER/PLANNING/INDEX.HTM If you have some free time check it out. Again, I want to thank everyone for sharing their opinions. joe jjlindula@hotmail.com wrote: > Hello, I'm interested in how individuals or design groups manage > complexity in their design projects. What things do you do or things > the group does that can take complex tasks and break them into simpler > or more manageable tasks? It may sound like a weird question, but there > must be some guidelines, best practices, or habits used to achieve > success in designing/developing a complex project. I'm sure there must > be some individuals out there that are constantly taking complex tasks > and just about every time have success with it. Short of speaking, I > want to know what's the secret to their success. All comments are > welcomed, even the most obvious suggestions. > > As an engineer, I'm constantly trying to improve my design processes. > > Thanks everyone, > joeArticle: 87596
Antti Lukats wrote: > "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag > news:42e58544$1@clear.net.nz... >>>"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag >>>news:42e540a2$0$8024$3b214f66@tunews.univie.ac.at... >>>>Just looked at the sources - There are binary VHDL files. What does >>>>this mean? >>>> >>>>Martin >>>This means they can only be used by ISE tools. There should be no problems >>>using those files with ISE 6.2 to 7.1, just add to your project and >>>synthesise as normal. If there are any problems let me know. >> >>?! - do you mean you cannot save as ASCII source code, or use any other >>editor ? >> Surely this nonsense can be disabled ? >> >>-jg > Sure, ask for commercial licensing and you will get readable source code > instantly. > At the moment the sources are encrypted to prevent modification. I think I miss-understood your first reply - I thought this was some new 'ISE feature', but it seems it is something you can enable/disable, to password IP sources, until paid - correct ? -jgArticle: 87597
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:42e69666$1@clear.net.nz... > Antti Lukats wrote: > > "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag > > news:42e58544$1@clear.net.nz... > >>>"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag > >>>news:42e540a2$0$8024$3b214f66@tunews.univie.ac.at... > >>>>Just looked at the sources - There are binary VHDL files. What does > >>>>this mean? > >>>> > >>>>Martin > >>>This means they can only be used by ISE tools. There should be no problems > >>>using those files with ISE 6.2 to 7.1, just add to your project and > >>>synthesise as normal. If there are any problems let me know. > >> > >>?! - do you mean you cannot save as ASCII source code, or use any other > >>editor ? > >> Surely this nonsense can be disabled ? > >> > >>-jg > > Sure, ask for commercial licensing and you will get readable source code > > instantly. > > At the moment the sources are encrypted to prevent modification. > > I think I miss-understood your first reply - I thought this was some > new 'ISE feature', but it seems it is something you can enable/disable, > to password IP sources, until paid - correct ? > -jg > correct. until paid for source license. AnttiArticle: 87598
Antti Lukats wrote: >> I think I miss-understood your first reply - I thought this was some >>new 'ISE feature', but it seems it is something you can enable/disable, >>to password IP sources, until paid - correct ? >>-jg >> > > correct. until paid for source license. ..and the price for that is.. ? -jgArticle: 87599
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:42e6a20d$1@clear.net.nz... > Antti Lukats wrote: > >> I think I miss-understood your first reply - I thought this was some > >>new 'ISE feature', but it seems it is something you can enable/disable, > >>to password IP sources, until paid - correct ? > >>-jg > >> > > > > correct. until paid for source license. > > ..and the price for that is.. ? > -jg > ok, as you asked then introductory offer - 1 company wide source code use license for the OCO library components for Spartan-3 2 free license for the clock analyzer application so you can perform the measurement accross chips and vcc/temp as needed 3 free license for the freq measurement ip cores (for the sw app) 4 free update/updgrade for Spartan-3E - as soon as we get S3E silicon for measurements and testing 5 tech support for instantition and use of the ip cores (per email) ==== 50 USD per paypal to antti@openchip.org Antti
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