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
I have desingned a board with an Atmega128 and Spartan3, such that the Atmega128 configures the FPGA via the slave serial method. In my current rev, the Atmega128 is powered by a 5V supply. The FPGA power supply is correct. The HSWAP_EN is tied low to ground. An general I/O on the microcontroller is tied to the FPGA pins. Anyways, the problem I am having is that I am not able to pull PROG_B low to reset the FPGA. The miroprocessor pin goes low but it is not able to pull the PROG_B low at all? The way I test this, is I have a JTAG port which I used to program the FPGA. After configruation the DONE signal goes high. So my understanding was that if I pull the PROG_B low from the microprocessor, I should be able to manually reset the FPGA and the DONE signal should go low. I need to solve this problem before I move on to the actual programming of the board using the CCLK and DIN signals, to which I will have attach series resistors because of the Atmega128 (5V) and FPGA(3.3V). Any suggestions or ideas appreciated. ThanksArticle: 95851
Hi I was wondering if I could get some help with a project I'm trying to get started, I'm trying to embed some C code in the PPC core of the Virtex II pro board, while I can get small application deployed i.e. all data and instructions reside in BRAM. The other code that I'm tying to embed is much larger and will not all reside here so I have added extra SDRAM the application builds correctly and downloads to the board however when I do so I get no output off the UART which is set as STDIN/STDOUT. Is there anyway to configure the memory of the board so that I will get some output so I can verify that it's working? I have tried using a different terminal program to read from the serial port and still no joy.The Baud rate and flow control all work for the smaller apps. If anybody could point me in the direction of a working example I would greatly appreciate it. I'm using XPS 7.1 along with ISE 7.1 Thanks Shane LynchArticle: 95852
In article <dra3db$oc9$00$1@news.t-online.com>, Antti Lukats <antti@openchip.org> wrote: ><fpga_toys@yahoo.com> schrieb im Newsbeitrag >news:1138257624.935300.25730@o13g2000cwo.googlegroups.com... >> >> Ray Andraka wrote: >>> Seems those who keep yelling for open bit streams aren't bothering to >>> look at what is available, or try working with pieces. They all seem to >>> want full open bitstream without even understanding what all it entails >>> to be able to successfully work with it. You could do pretty much >>> everything they seem to be looking to do within the existing XDL >>> framework, and it gives the ability to use parts of the existing tools >>> so you don't have to develop the entire tool chain from soup to nuts. >>> Pick a piece of it and plug it into the existing tools. >> >> It's not clear that XDL is in fact an official interface that will >> avoid a >> C&D order from Xilinx .... if it were completely documented, and the >> parts data bases behind it completely documented, then your assertion >> would be clearly true ... however, it isn't. Some reverse engineering >> in unavoidable to use it fully, and that has clear restrictions from >> Xilinx. >> >> So, given that the JHDLBits project bit the dust at Xilinx's hands, and >> it creaps into the same technology, and that Xilinx doesn't offically >> bless this interface to the degree of openess you suggest, let's just say >> it >> would be prudent to go a LOT slower in addopting it as the golden >> technology >> you suggest. >> > >1) XDL is official interface, any tools that parse and/or generate/modify >XDL for any purpose are OK. You say this based on discussions with Xilinx? By what authority do you make this statement? (just checking) >2) Xilinx can not make anyone or ar project to 'bit the dust' as you are >saing. Well, if the JHDLBits folks were sent a cease and desist order from Xilinx Lawyers (have we established that to be true?) that would certainly have a chilling effect, no? Open source developers and university students usually have no money to fight such an order so, in effect, it would kill the project. > >If some entity developes something that has real value, then Xilinx will buy >that entity (not kill!). But it sounds as if the JHDLBits folks developed something that had real value. > >If some open source project has no interest and no funding then it dies >eventually, all by itself. So that what has happened. Are you sure? Then why isn't JHDLBits downloadable then? While the papers are still available (they're academic papers which would be difficult to get removed) the code doesn't seem to be. > >All RE needed can arranged to be done by some untouchable entity if it >really comes to it. > >But for Xilinx bitstream support there is a lot that can be done without any >RE > >first as Ray has also said the XDL contains pretty much 100% of the physcial >design info. >the .LL files contains pretty much bit locations for purposes like post >bitgen bitstream patching, etc.. > Which tool produces the .LL file? >there are so far no tools that actually do something useful with XDL and LL >files, and I am sure Xilinx would welcome such open source projects. > We can hope. PhilArticle: 95853
Yaju Nagaonkar wrote: >...> Anyways, the problem I am having is that I am not able to pull PROG_B > low to reset the FPGA. The miroprocessor pin goes low but it is not > able to pull the PROG_B low at all? > What do you really mean? The output pin goes Low, but the PROG pin does not? What is between these pins, more than a strip of copper? Pewter Alfke, XilinxArticle: 95854
In article <umzhjnnjz.fsf@trw.com>, Martin Thompson <martin.j.thompson@trw.com> wrote: >fpga_toys@yahoo.com writes: > >> Ray Andraka wrote: >> > Seems those who keep yelling for open bit streams aren't bothering to >> > look at what is available, or try working with pieces. They all seem to >> > want full open bitstream without even understanding what all it entails >> > to be able to successfully work with it. You could do pretty much >> > everything they seem to be looking to do within the existing XDL >> > framework, and it gives the ability to use parts of the existing tools >> > so you don't have to develop the entire tool chain from soup to nuts. >> > Pick a piece of it and plug it into the existing tools. >> >> It's not clear that XDL is in fact an official interface that will >> avoid a >> C&D order from Xilinx .... if it were completely documented, and the >> parts data bases behind it completely documented, then your assertion >> would be clearly true ... however, it isn't. Some reverse engineering >> in unavoidable to use it fully, and that has clear restrictions from >> Xilinx. > >It is documented - in the XDL files it produces. The parts databases >are also documented in a fashion, as you can ask the XDL tool to dump >them for you in XDL format. Good points. But the tricky part is when we start parsing those files. I would tend to think that since they are not encrypted that it's legal to parse them, but IP laws in recent years have gotten very restrictive (think DMCA) and who knows if Xilinx would interpret that as 'reverse engineering'. > >And XDL is used by parts of the Xilinx tool flow, so it's unlikely to >go away. > >You should be able to solve all your placement problems with XDL and >then feed the results into the router (which will do a reasonable job >once it has a good placement). > I guess I'm starting to lean towards the idea of let's give it a try and see what happens. PhilArticle: 95855
Ed McGettigan wrote: > I believe that it is established copyright law that SW interface > specs are not protectable elements although there appear to be > some gray areas. Software copyrights yes, but Xilinx claims a business contract license to protect IP in the release ... that is different law, and to violate the license is breach of contract. > The XDL tool explicitly states that you are allowed to create tools > that use the output of NCD2XDL or tools that create input for XDL2NCD. > This use of course is restricted to use for Xilinx devices per the > ISE 8.1i EULA. It is this "restricted to use for Xilinx devices" that violates every open source license, and which as a developer using BSD licenses that we can not accept (nor does any other accepted open source license). Be cause of this restriction, there is no forum where the software can be released, as it's impossible to acertain that the recipient is also bound by the Xilinx license terms. Open source requires that no restrictions be placed on the distribution, other than governmental. So read the EULA carefully, as the business contract language requires that you protect the IP assets you aquire as part of the license ... as they are trade secret and proprietary ... not public domain, and free to distribute.Article: 95856
On 2006-01-26, Antti Lukats <antti@openchip.org> wrote:
><fpga_toys@yahoo.com> schrieb im Newsbeitrag
> news:1138297173.649950.136370@g14g2000cwa.googlegroups.com...
>> So the question to Xilinx is, will Xilinx release the NDA restrictions
>> on XDL, and the associated library interfaces so that open source tools
>> can legally target ISE supported FPGAs?
>>
>> It's pretty clear that most of the regulars here, just assume that XDL
>> and the associated libraries, are an open interface, and think it's ok
>> to ignore the IP restrictions in the ISE license. The legaleze says
>> otherwise.
>>
>> So how about a clear definative legal statement about what are legal
>> ISE interfaces for open source development.
>>
>
> you are constantly talking about NDA restricted XDL documents, as if you
> have signed an NDA with Xilinx and received special documents under that NDA
> agreement, in wich case its better for you that read those NDA agreements
> (signed by you and Xilinx) over again. If you have not signed such
> agreements then stop talking about NDA in this context.
The conservative assumption is that the EULA we all click when
we install ISE is a valid document, and it has NDA-like clauses.
The poster has clearly read that NDA very carefully.
If you live in a country where such agreements are non-binding,
let us know here. Then software developers in that country can
proceed without fear -- until Xilinx stops exporting chips and
software to that country for the same reason.
> As of your Question to Xilinx - do not expect an reply as it totally unclear
> what you are actually asking as you have not defined that.
It's clear to me. Are you being willfully disingenuous?
Well, maybe some clarification should be made of the phrase
"associated library interfaces".
> In the form you
> asked your question it would deserve a "NO" as replay from any entity that
> has any understanding of legal matters. Xilinx can not say YES to your
> question. Well you probably know that yourself. So what are you trying to
> achive with your push?
In the short run, maybe the regulars will admit that XDL can not
currently be considered an open interface. In the long run, maybe
we can pressure Xilinx to remove NDA restrictions on information
contained in XDL data files, to permit open source code to monkey
with FPGA internals (without fear of being JHDLBits-ized). Presumably
that means Xilinx's engineers and lawers have to have a serious
talk, since a Xilinx lawyer can hardly be expected to say "YES"
to a request he doesn't understand.
Only after this is resolved, can the regulars here go back to
telling people who want to make bitstreams with open source
software to use XDL instead.
- Larry
Article: 95857In article <drai9p$tru$00$1@news.t-online.com>, Antti Lukats <antti@openchip.org> wrote: ><fpga_toys@yahoo.com> schrieb im Newsbeitrag >news:1138281184.454302.70800@g14g2000cwa.googlegroups.com... >> >> Martin Thompson wrote: >>> fpga_toys@yahoo.com writes: >>> > It's not clear that XDL is in fact an official interface that will >>> > avoid a >>> > C&D order from Xilinx .... if it were completely documented, and the >>> > parts data bases behind it completely documented, then your assertion >>> > would be clearly true ... however, it isn't. Some reverse engineering >>> > in unavoidable to use it fully, and that has clear restrictions from >>> > Xilinx. >>> >>> It is documented - in the XDL files it produces. The parts databases >>> are also documented in a fashion, as you can ask the XDL tool to dump >>> them for you in XDL format. >> >> To get those files requires assuming the license terms of >> non-disclosure. >> It remains a controlled and propietary format until such a time that >> Xilinx releases it in a public documents, outside those license terms. >> > >there is no non-disclosure > >just download ISE webpack and run XDL, there is no license above the >standard webpack license > except that when you download WebPack you agree to a certain license. One of the stipulations of that license is apparently non-disclosure and another prohibits reverse engineering. It's a tricky area these days... Interesting that nobody from Xilinx has commented about what happened to JHDLBits, nor has anyone from there commented about open source tools using XDL. PhilArticle: 95858
There was a 242 ohm resistor to limit the current into PROG_B since, the microcontroller is at 5V and PROG_B has to be at VCCAUX(2.5V). I tried to remove the resistor and connected the PROG_B to the microncontroller I/O. The FPGA still would not reset when the Microcontroller I/O was held low. The FPGA resets only when I connect a wire from the PROG_B pin to GND directly.Article: 95859
John, I am not a lawyer. But it seems clear to me, when I read it: the answer is "none." To imply otherwise is clearly misleading, and could be interpreted as intentionally causing harm (to Xilinx, or its partners, or its customers). A retraction on your part would be completely acceptable, and your statement that you will immediately cease and desist the use of our tools against the agreement you signed is most welcome. For anyone seeking to do anything that they are unsure about, I suggest you contact our legal staff. http://www.xilinx.com/legal.htm AustinArticle: 95860
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag news:drb64u$nga5@cliff.xsj.xilinx.com... > fpga_toys@yahoo.com wrote: >> So the question to Xilinx is, will Xilinx release the NDA restrictions >> on XDL, and the associated library interfaces so that open source tools >> can legally target ISE supported FPGAs? >> >> It's pretty clear that most of the regulars here, just assume that XDL >> and the associated libraries, are an open interface, and think it's ok >> to ignore the IP restrictions in the ISE license. The legaleze says >> otherwise. >> >> So how about a clear definative legal statement about what are legal >> ISE interfaces for open source development. >> > > I believe that it is established copyright law that SW interface > specs are not protectable elements although there appear to be > some gray areas. This seems to be a good write up from 1997 > http://www.fenwick.com/docstore/publications/IP/IP_Articles/Baystate_Holding.pdf > > In any case here is the output of the XDL tool in ISE 8.1i > > unix> xdl -help > Release 8.1i - xdl I.24 > Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. > > Xdl is a single tool with 3 fundamental modes: > > * Report Device Resource Information > * Convert NCD to XDL (ncd2xdl) > * Convert XDL to NCD (xdl2ncd) > > Report generates a report of the physical resources > available for a specific part. > > Ncd2xdl reads in an NCD file and generates an ASCII XDL file. > > Xdl2ncd reads in an XDL file and generates an NCD file. > > XDL is also a fully featured Physical Design language that > provides direct read and write access to Xilinx's proprietary > Native Circuit Description (NCD). This access enables all > users to write tools to address their individual FPGA > design needs. > > The XDL tool explicitly states that you are allowed to create tools > that use the output of NCD2XDL or tools that create input for XDL2NCD. > This use of course is restricted to use for Xilinx devices per the > ISE 8.1i EULA. > > If you want to make a tool that writes XDL or a tool that does > a read/modify/write using XDL for Xilinx devices open source > go ahead. > > We have released application notes that explain how to use XDL to > modify elements in a design. Some companies like Hier Design created > and marketed their own tools using this interface. We liked the > Hier Design tool so much we bought the company. > > I don't know what you mean by "NDA restrictions on XDL". I can't > find any reference to a NDA documentation. > > Ed Hi Ed, I wasnt quite sure if there are actual XDL documentation under NDA so I have replied (several replies in other treads) based on my best knowledge, eg stating that is OK to dvelop tool that use or generate XDL, well good to have that confirmed one more time. My reply to mr fpga_toys original post was to his question in general where he messes up XDL and interface and libraries and ISE and seems to request to opensource everything that is needed to generate bitstreams for Xilinx devices in general - at least that is how I did understand his question, and answer to the question int that form is defenetly no. As extension to XDL I belive the .LL file are also 'legal' source of information about Xilinx bitstreams so that 3rd parties can develop software and utilities that either patch bitstreams or perform partial reconfiguration or use readback features. So the use of XDL and LL files is defenetly sufficent to create different type of tools that can target Xilinx FPFA very close to the actualy physical implementation level. And I was and am sure that any such tools (of professional quality) would be welcomed by Xilinx as they do provide additional features and functionality for the users of Xilinx FPGA's. AnttiArticle: 95861
Antti Lukats wrote: > As extension to XDL I belive the .LL file are also 'legal' source of > information about Xilinx bitstreams so that 3rd parties can develop > software and utilities that either patch bitstreams or perform > partial reconfiguration or use readback features. The format of the file is useless without also being able to specify objects proprietary to Xilinx, and not part of the XDL format itself The real problem, is that all the licenses do not allow open source, and are restricted to your own development because the license doesn't specfically grant distribution rights of derived IP. The whole "patch bitstreams" is where you quickly get into IP outside the XDL format. > And I was and am sure that any such tools (of professional quality) > would be welcomed by Xilinx as they do provide additional > features and functionality for the users of Xilinx FPGA's. But not open source as long as the xilinx only restriction is in place. And certainly not on sourceforge, or other widely used public distribution point.Article: 95862
Phil Tomson" <ptkwt@aracnet.com> schrieb im Newsbeitrag news:drb7dd11ie4@enews4.newsguy.com... > In article <dra3db$oc9$00$1@news.t-online.com>, > Antti Lukats <antti@openchip.org> wrote: >><fpga_toys@yahoo.com> schrieb im Newsbeitrag >>news:1138257624.935300.25730@o13g2000cwo.googlegroups.com... >>> >>> Ray Andraka wrote: >>>> Seems those who keep yelling for open bit streams aren't bothering to >>>> look at what is available, or try working with pieces. They all seem >>>> to >>>> want full open bitstream without even understanding what all it entails >>>> to be able to successfully work with it. You could do pretty much >>>> everything they seem to be looking to do within the existing XDL >>>> framework, and it gives the ability to use parts of the existing tools >>>> so you don't have to develop the entire tool chain from soup to nuts. >>>> Pick a piece of it and plug it into the existing tools. >>> >>> It's not clear that XDL is in fact an official interface that will >>> avoid a >>> C&D order from Xilinx .... if it were completely documented, and the >>> parts data bases behind it completely documented, then your assertion >>> would be clearly true ... however, it isn't. Some reverse engineering >>> in unavoidable to use it fully, and that has clear restrictions from >>> Xilinx. >>> >>> So, given that the JHDLBits project bit the dust at Xilinx's hands, and >>> it creaps into the same technology, and that Xilinx doesn't offically >>> bless this interface to the degree of openess you suggest, let's just >>> say >>> it >>> would be prudent to go a LOT slower in addopting it as the golden >>> technology >>> you suggest. >>> >> >>1) XDL is official interface, any tools that parse and/or generate/modify >>XDL for any purpose are OK. > > You say this based on discussions with Xilinx? By what authority do you > make > this statement? (just checking) > >>2) Xilinx can not make anyone or ar project to 'bit the dust' as you are >>saing. > > Well, if the JHDLBits folks were sent a cease and desist order from Xilinx > Lawyers (have we established that to be true?) that would certainly have a > chilling effect, no? Open source developers and university students > usually > have no money to fight such an order so, in effect, it would kill the > project. > >> >>If some entity developes something that has real value, then Xilinx will >>buy >>that entity (not kill!). > > But it sounds as if the JHDLBits folks developed something that had real > value. > >> >>If some open source project has no interest and no funding then it dies >>eventually, all by itself. So that what has happened. > > Are you sure? Then why isn't JHDLBits downloadable then? While the > papers are > still available (they're academic papers which would be difficult to get > removed) the code doesn't seem to be. > >> >>All RE needed can arranged to be done by some untouchable entity if it >>really comes to it. >> >>But for Xilinx bitstream support there is a lot that can be done without >>any >>RE >> >>first as Ray has also said the XDL contains pretty much 100% of the >>physcial >>design info. >>the .LL files contains pretty much bit locations for purposes like post >>bitgen bitstream patching, etc.. >> > > Which tool produces the .LL file? > >>there are so far no tools that actually do something useful with XDL and >>LL >>files, and I am sure Xilinx would welcome such open source projects. >> > > We can hope. > > Phil Hi Phil, I replied based on my 'feeling' and best knowledges, but Ed McGettigan already answered the XDL use issue in more details pretty much confirming what I have said, eg it is ok to use/parse and modify/generate XDL .LL is generated by bitgen it hold frame address and offset of RAM bits any flip flops it is intended for readback verification, can be used to read back RAM contents or register content, can also be used to initialize FF and RAMs or to change the values during partial configuration AnttiArticle: 95863
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138304609.649172.148320@z14g2000cwz.googlegroups.com... > > Antti Lukats wrote: >> As extension to XDL I belive the .LL file are also 'legal' source of >> information about Xilinx bitstreams so that 3rd parties can develop >> software and utilities that either patch bitstreams or perform >> partial reconfiguration or use readback features. > > The format of the file is useless without also being able to specify > objects proprietary to Xilinx, and not part of the XDL format itself > > The real problem, is that all the licenses do not allow open source, > and are restricted to your own development because the license > doesn't specfically grant distribution rights of derived IP. > > The whole "patch bitstreams" is where you quickly get into IP outside > the XDL format. > >> And I was and am sure that any such tools (of professional quality) >> would be welcomed by Xilinx as they do provide additional >> features and functionality for the users of Xilinx FPGA's. > > But not open source as long as the xilinx only restriction is in place. > And certainly not on sourceforge, or other widely used public > distribution > point. > and you mr fpga_toys are still an ..... ...... (everyone please fill in the blanks) Antti PS I self-censored my previous response to mr fpga_toys.Article: 95864
Hi, all I know some files in the folder: C:\EDK\hw\XilinxProcessorIPLib\pcores\proc_common_v2_00_a\hdl\vhdl. But when I used the XP search program to look for them, it can't find the files. I wonder whether these lib files are encrypted to prevent us from finding? BTW, what i am trying to find is: I am trying to find async_fifo_v4_0.vhd. Thanks.Article: 95865
Measure the current in that wire with a milliampere-meter. That gives you a feel for the strength of the pull-up transistor or resistor that you must overcome. Also, there is no need for 242 Ohm. You want to limit the current between 5 V and 2.5V + one diode drop. 100 Ohm would limit it to max 18 mA, which is fine. Peter AlfkeArticle: 95866
In article <draosp$f6u$00$1@news.t-online.com>, Antti Lukats <antti@openchip.org> wrote: ><fpga_toys@yahoo.com> schrieb im Newsbeitrag >news:1138287854.181856.171000@g14g2000cwa.googlegroups.com... >> >> Antti Lukats wrote: >>> <fpga_toys@yahoo.com> schrieb im Newsbeitrag >>> > To get those files requires assuming the license terms of >>> > non-disclosure. >>> > It remains a controlled and propietary format until such a time that >>> > Xilinx releases it in a public documents, outside those license terms. >>> > >>> >>> there is no non-disclosure >>> >>> just download ISE webpack and run XDL, there is no license above the >>> standard webpack license >> >> The standard ISE license contains: >[snippped] > >> These are clearly broad and inclusive terms which cover all aspects of >> using derived and derivative IP based on materials contained in the >> release. >> >> AKA ... no open source access to disclosed interfaces inside this >> material. >> > >gosh, of course you can not use any interfaces or pieces of the xilinx >licensed material. Thats clear. > >XDL is just an readable ASCII file format. if your tool generates XDL then >its ok, as long as you do not use any parts of materials from Xilinx. But what's legally questionable is whether we can take an XDL file, generated by the Xilinx tools, parse it and then modify it and feed it back in. > >XDL is meant as interchangeable file format, like EDIF. But EDIF is a recognized standard while XDF could be construed by Xilinx to be an internally used file format. The fact that it's human readable could be incidental. The fact that XDL is human readable is potentially helpful (meaning that no decryption is required) but still there's doubt. The IP laws in the US have really become quite draconian (and we're exporting those kinds of laws all over the world now ). > You can use it if >you want. But you must of course be aware of the different license agreement >tems, sure. Well, and one of those terms is that there be no derivative works. If someone creates an XDL parser/generator and then uses that to create some sort of layout modifier that could easily be considered to be a derivative work, no? Now that's the letter of the law (or license agreement), but perhaps the intent is to prevent you from creating derivative works that could be used to program other non-Xilinx FPGAs? Maybe Xilinx wouldn't mind if you develop tools around XDL that improve performance (as long as you stay away from the bitstream). Some even seem to be suggesting in this thread that Xilinx has released XDL so that people will lose interest in messing with the bitstream and that they would be happy if people would develop tools around XDL - if so, it would be nice to hear that from Xilinx. PhilArticle: 95867
"Yaju Nagaonkar" <yaj_n@hotmail.com> schrieb im Newsbeitrag news:1138303895.360065.315910@g43g2000cwa.googlegroups.com... > There was a 242 ohm resistor to limit the current into PROG_B since, > the microcontroller is at 5V and PROG_B has to be at VCCAUX(2.5V). > > I tried to remove the resistor and connected the PROG_B to the > microncontroller I/O. The FPGA still would not reset when the > Microcontroller I/O was held low. The FPGA resets only when I connect a > wire from the PROG_B pin to GND directly. > PROG_B is input only on FPGA with virtually no current, so if you nee strong pulldown to get it to low level there must be something else pulling it up, not FPGA AnttiArticle: 95868
Xilinx Website is a good source for information too... http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=19146Article: 95869
Marco T. wrote: > Hallo, > I would insert multichannel opb sdram controller into a project. > > I would use xcl bus to access read/write datas into a integer matrix. > > I would know if every time I would perform read/write operations into a > element of the matrix I need to: > > 1) disable data cache > 2) init cache with address of matrix element > 3) enable cache > > Is it correct? > > Following that the system copy the region of sdram into bram cache to > perform operations on it? > > Many Thanks > Marco > > Hi Marco, If your matrix is stored in the sdram, you don't need to disable the cache to read/write the contents of the matrix. The accesses on the xcl bus is only read cachemiss cacheline fills and write through address/data. It's not a general bus for doing a fetch of a whole matrix. Göran BilskiArticle: 95870
In article <drarmt$t2s$03$1@news.t-online.com>, Antti Lukats <antti@openchip.org> wrote: ><fpga_toys@yahoo.com> schrieb im Newsbeitrag >news:1138289887.289407.179820@o13g2000cwo.googlegroups.com... >> >> Antti Lukats wrote: >>> <fpga_toys@yahoo.com> schrieb im Newsbeitrag >>> > AKA ... no open source access to disclosed interfaces inside this >>> > material. >>> >>> gosh, of course you can not use any interfaces or pieces of the xilinx >>> licensed material. Thats clear. >>> >>> XDL is just an readable ASCII file format. if your tool generates XDL >>> then >>> its ok, as long as you do not use any parts of materials from Xilinx. >>> >>> XDL is meant as interchangeable file format, like EDIF. You can use it if >>> you want. But you must of course be aware of the different license >>> agreement >>> tems, sure. >> >> NO ... absolutely not. >> >> EDIF has it's format publicly disclosed. There is no corresponding >> document for XDL ... so just producing XDL files with open source software >> would >> use material under the licenses NDA in voilation of it's terms ... >> specifically disclosing the file format without permission, and having >> developed > >well you really sound paranoid about the issue. Given the state of US IP law, being paranoid is understandable. That's why I really wanted to have a good discussion about the issue before spending any time or effort on any open source tools like this... >If you do some tools that >produce XDL and help xilinx to sell their silicon they will not go hunting >you down. In how many different ways I have to say that? We can only hope that you're right. However, the argument can be made that the JHDLBits folks created a suite of tools that could have helped sell silicon and apparenlty they were shut down. Personally, I tend to think that Xilinx shut them down because they were getting too intimate with the bitstream and that working with XDL would be acceptable to Xilinx... but I'm not 100% convinced of that. The way the laws are written Xilinx holds all the cards meaning that while they might initially smile upon your efforts (or at least ignore them) they could at any time change their mind. Really, to some extent it doesn't even matter what a license agreement says; if a corporation sends lawyers after you and you're just a little guy, you're not going to be able to afford to press the issue - you'll immediately pull the software and never mention it again if you like living in a house and eating regularly ;-) > >If you start an open-source project that is totally useless but exposes all >xilinx internals they will get upset. And with good cause. Sure, and that's certainly not the intent, but who knows how it could be interpreted? PhilArticle: 95871
Andy Peters wrote:
[ ... ]
> If your software doesn't work, you tell the customer, "download a patch
> from our web site."
>
> If your hardware doesn't work, you tell the customer, "here's your RMA
> number. Send the unit back (at your expense) and if it's under
> warrantee we'll fix it for free; otherwise, it'll cost $$$."
Hmmm...did I somehow end up in the wrong newsgroup? I thought this was
comp.arch.fpga, where if your hardware doesn't work, you tell the
customer "download a patch from our web site" -- thus the name _field
programmable_ gate array. Granted, it's entirely possible to use an
FPGA in a design that doesn't allow its associated Flash to be updated
-- but it's certainly a long ways from a given.
--
Later,
Jerry.
Article: 95872In article <1138291842.657681.212890@g44g2000cwa.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >Antti Lukats wrote: >> well you really sound paranoid about the issue. If you do some tools that >> produce XDL and help xilinx to sell their silicon they will not go hunting >> you down. In how many different ways I have to say that? > >Or we could set the stage for another open source witch hunt, with >Xilinx >lawyers going after all the competitors and users asking for license >payments >like SCO. > >The whole SCO wake up call is that we deal with IP rights properly, up >front, >or stay clear -- and don't expect everyone to be greatful when you >steal IP >from some big company. > It seems like the whole SCO vs IBM issue has now just devolved into an issue of SCO trying to stay alive as long as they can by lawsuits. While initially some in the open source community were afraid that SCO might have a case, now it's widely agreed that they never had a leg to stand on. It appears that SCO had no compelling products that would attract customers anymore, so instead of trying to compete they decided to litigate. PhilArticle: 95873
Antti Lukats wrote: > > > and you mr fpga_toys are still an ..... ...... > (everyone please fill in the blanks) > > Antti > > PS I self-censored my previous response to mr fpga_toys. > > Antti, Time to stop feeding the troll. We've given Mr. FPGA_toys the information about the hooks he needs to work within the framework of the xilinx tools. He's obviously not going to be happy unless they decide to make the entire tool chain open source. I'm not sure I understand why he is on this crusade. One doesn't need open source in order to read and write to the XDL chain. Xilinx encourages third party tools using XDL, as evidenced by the text at the beginning of an XDL file as well as the statement here on the news group by Ed McGettigan. I've come to the conclusion that MrFPGA is not looking for a solution, rather he is simply trolling. We've offered a solution, but he continues to use misdirection to try and poke holes in it because it doesn't meet his desire for totally open source. He also claims any XDL tools he creates cannot be distributed, which is bunk. He can't distribute Xilinx tools or IP, but he can certainly distribute a tool that talks to the xilinx tools through a published ascii interface that has the permission to use it printed right in every file generated by it. I think XDL is a very reasonable approach by Xilinx to offer hooks into its tools without having to give away the farm. JHDLbits, as I understand it (not sure where MrFPGA is getting his info, I think he's making a lot of it up), used information directly supplied by Xilinx under NDA, and included some of that information in the distribution, which was a violation of the NDA. XDL is provided under an end user license agreement, not an NDA. Making a tool to interface to it, from what I can see does not violate any terms of the EULA, provided you don't include the xilinx tools with any distributions of your XDL tool.Article: 95874
Ok. It works now. I cleaned up all the solder from the pin connections and I disconnected a pull-up on the PROG_B pin. The pull up was tied to 2.5V(VCCAUX) vias 4.7K. It was a simple mistake which I should have fixed on my own. Basically I need to learn to solder things neatly. I have already looked at the website which earlier JPdull has mentioned. I will move on to the other signals, names CCLK and DIN. Again, since my micro-controller (5v) is driving these signals, I will be using series resistors (300ohm) to limit the current to these pins. Thanks everyone.
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