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
Antonio Pasini wrote: > Il 18/11/2007 0.12, Didi ha scritto: > >> A few hours of digging later I found out that the JTAG >> sequences needed to write to a XPLA3 and Coolrunner-II >> are publically available. >> However, the JEDEC -> JTAGgable fuse address translation >> map is not (I do have that for the Philips Coolrunner, >> the bit locations in the JTAG sequence descriptions have >> nothing to do with the bit locations in the JEDEC file). > > > Dimitri, I'm not sure I understood what your problem is; do you need to > write your own JTAG programmer routines ? > > In last project I did I had to program (or re-program) a CoolrunnerII > (XC2C256) by JTAG with a microcontroller. Xilinx provides all the info > you need in their app notes. > > It was not so difficult; in fact, it works so well I'm using that also > on production. Just a second to program a XC2C256, reasonably filled. > > 1) Tweak the XAPP058 code for your platform; easy, that code is meant to > be "easily" ported. > > 2) suppose I have my foo.jed file to program (made for XC2C256) > > 3) use Impact (free download) to translate the jedec in a XSVF binary > file. You can do on GUI by hand, or by makefile as I prefer; syntax is: > > impact -batch impact_make_xsvf.cmd > > where "impact_make_xsvf.cmd" contains: > > setMode -bs > setCable -port xsvf -file "foo.xsvf" > addDevice -p 1 -file "foo.jed" > Program -p 1 -e -v -defaultVersion 0 > quit > > 4) write (or google..) a little utility (BIN2C) to convert your binary > XSVF image file in a C const array in source form, or include it > directly with assembly directives, if any, or whatever you think. > > 5) the "player" in XAPP058 will erase, blank check, program and verify > your device. > > > In fact, they did all the hard work for you, and provide also the source > of the jtag "player". > > You don't need to pay anyone to do the translation, just use the free > Impact tool. And yes, it works even without network connection (no > spyware, I think!). That is also a good suggestion. What code/data size was the microcontroller 'SVF/Jatg player' ? -jgArticle: 126326
> It was not so difficult; in fact, it works so well I'm using that also > on production. Just a second to program a XC2C256, reasonably filled. I know it is not difficult at all, like I said, I have made it - and a lot more than that - for the original coolrunner 5-6 years ago. > 1) Tweak the XAPP058 code for your platform; easy, that code is meant to > be "easily" ported. > > 2) suppose I have my foo.jed file to program (made for XC2C256) So far I am accepting that (using xilinx software to create the jedec file, I'd accept this precedent here). > > 3) use Impact (free download) to translate the jedec in a XSVF binary > file. You can do on GUI by hand, or by makefile as I prefer; syntax is: > Now this is a hoop I can do without. XAPP058 actually states you have to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely available. Is the tool for doing jedec->svf also freely available? Can you point me to it please? Thanks, Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 12:11 am, Antonio Pasini <removethis_antonio.pas...@alice.it> wrote: > Il 18/11/2007 0.12, Didi ha scritto: > > > A few hours of digging later I found out that the JTAG > > sequences needed to write to a XPLA3 and Coolrunner-II > > are publically available. > > However, the JEDEC -> JTAGgable fuse address translation > > map is not (I do have that for the Philips Coolrunner, > > the bit locations in the JTAG sequence descriptions have > > nothing to do with the bit locations in the JEDEC file). > > Dimitri, I'm not sure I understood what your problem is; do you need to > write your own JTAG programmer routines ? > > In last project I did I had to program (or re-program) a CoolrunnerII > (XC2C256) by JTAG with a microcontroller. Xilinx provides all the info > you need in their app notes. > > It was not so difficult; in fact, it works so well I'm using that also > on production. Just a second to program a XC2C256, reasonably filled. > > 1) Tweak the XAPP058 code for your platform; easy, that code is meant to > be "easily" ported. > > 2) suppose I have my foo.jed file to program (made for XC2C256) > > 3) use Impact (free download) to translate the jedec in a XSVF binary > file. You can do on GUI by hand, or by makefile as I prefer; syntax is: > > impact -batch impact_make_xsvf.cmd > > where "impact_make_xsvf.cmd" contains: > > setMode -bs > setCable -port xsvf -file "foo.xsvf" > addDevice -p 1 -file "foo.jed" > Program -p 1 -e -v -defaultVersion 0 > quit > > 4) write (or google..) a little utility (BIN2C) to convert your binary > XSVF image file in a C const array in source form, or include it > directly with assembly directives, if any, or whatever you think. > > 5) the "player" in XAPP058 will erase, blank check, program and verify > your device. > > In fact, they did all the hard work for you, and provide also the source > of the jtag "player". > > You don't need to pay anyone to do the translation, just use the free > Impact tool. And yes, it works even without network connection (no > spyware, I think!).Article: 126327
> > Well the fact of the matter is that there is no CPLD on the market > > to compete with all the coolrunner parameters at the same time - and > > I do use them. > > Across the size range, you may be right. > But at the highest volume end Atmel and Lattice have good low power > offerings. Actel may start to impact > 128MC CPLDs I would be really happy to see an alternative to the coolrunner, especially if its documentation is less secretive. Until then, we are all stuck with xilinx for CPLDs above a certain complexity and below some power, which is why I am still trying to get some way to use them (notice I even accept to use their software to produce the jedec file, something unprecedented here). > My understanding there is the parts were not externally foundry fab'd > and when the plug was pulled on the fab line, that then killed the > product line. ... Well I do not find it very plausible - making a new coolrunner line from scratch cannot have been easier than repeating an existing product, mask sets and all being available. But whatever, their agreement with Philips was to support all existing customers the way Philips had supported them. This has not been the case with us - we do have the jedec -> jtag maps from Philips and we do not have these from Xilinx. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 1:03 am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > >>The Atmel devices top out at 128 macrocells, but you can pack > >>a little more into a Atmel macrocell. > >>The new BE family, are uA static devices, in 32/64 MC (released) > >>and 128MC (soon) > > > Well the fact of the matter is that there is no CPLD on the market > > to compete with all the coolrunner parameters at the same time - and > > I do use them. > > Across the size range, you may be right. > But at the highest volume end Atmel and Lattice have good low power > offerings. Actel may start to impact > 128MC CPLDs > > > Philips could have taken over the sector with that device easily, > > we'll never know what happened behind the scenes so they sold it to > > xilinx - who immediately killed the original Philips line which was > > great but had leaked out programming information (no other plausible > > reason for killing such a good device I can think of). > > My understanding there is the parts were not externally foundry fab'd > and when the plug was pulled on the fab line, that then killed the > product line. (similar problem happened with some Lattice.AMD parts) > > Not good for the end customers. - but certainly not a conspiracy, > instead a by-product of some decoupled bean-counter's decisons, and > we have all seen that before ! :) > > > And now we stand with xilinx having monopoly over the only up-to-date > > CPLD on the market, and they will not let you write to it without > > revealing your written code to them (oh yeah, they'll swear to god > > their software only translates one map to another and I am just > > paranoid because I think it is the spyware it actually is - but > > ask them _why_ do they keep that jedec -> jtag mapping data secret > > and feel free to wait for another century for a plausible answer). > > That is a good question. > > Comments Austin ? ( or Jesse? ) > > -jgArticle: 126328
> > Well the fact of the matter is that there is no CPLD on the market > > to compete with all the coolrunner parameters at the same time - and > > I do use them. > > I feel your pain. It is often that I need devices with 5 volt > tolerance. But that makes it difficult to migrate to the finer > processes which lower the cost of devices. > ... I do need less and less of the 5V tolerance (but still not easy to replace in some instances - say an ATA interface which is 5V for 2.5" and 3.5" devices). Actually the coolrunner-II is more appealing for the future because it has a variety of I/O voltage options, most of these are already in demand... I am glad I am not the only one feeling the pain of having to deal with the defacto monopoly of Xilinx on the high end/low power CPLD market. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 12:35 am, rickman <gnu...@gmail.com> wrote: > On Nov 19, 4:27 pm, Didi <didi...@gmail.com> wrote: > > > > The Atmel devices top out at 128 macrocells, but you can pack > > > a little more into a Atmel macrocell. > > > The new BE family, are uA static devices, in 32/64 MC (released) > > > and 128MC (soon) > > > Well the fact of the matter is that there is no CPLD on the market > > to compete with all the coolrunner parameters at the same time - and > > I do use them. > > I feel your pain. It is often that I need devices with 5 volt > tolerance. But that makes it difficult to migrate to the finer > processes which lower the cost of devices. Adding extra processing to > retain 5 volt tolerance drives the price back up. I can't say which > of the two is more significant, but it is interesting that many MCU > vendors seem able to produce 5 volt tolerant devices in the newer > processes at *VERY low* prices. > > I looked at exactly this issue a bit over a year ago and came up with > the XPLA family and the Lattice parts. Xilinx won't compete on price > with the XPLA line because it is not one of the new lines they are > pushing. I think they literally don't care a hoot about design wins > with older logic. At least the sales people are always pushing the > new stuff even after I have told them why it is not suited (or they > have not been able to tell me how I will be able to get these new > parts in preproduction). Clearly there is a lot of incentive to > salesmen for design wins with the new parts over the old. > > > Philips could have taken over the sector with that device easily, > > we'll never know what happened behind the scenes so they sold it to > > xilinx - who immediately killed the original Philips line which was > > great but had leaked out programming information (no other plausible > > reason for killing such a good device I can think of). > > Philips and Xilinx have different processes. Xilinx adjusted the > design to suit their manufacturing and to improve it in some ways. > They may not be willing to share detailed info, but I don't think they > would go to the expense of redesigning a chip line just to prevent > users from having "programming information". > > > And now we stand with xilinx having monopoly over the only up-to-date > > CPLD on the market, and they will not let you write to it without > > revealing your written code to them (oh yeah, they'll swear to god > > their software only translates one map to another and I am just > > paranoid because I think it is the spyware it actually is - but > > ask them _why_ do they keep that jedec -> jtag mapping data secret > > and feel free to wait for another century for a plausible answer). > > You're only paranoid because everyone is out to get you! You don't > have to literally give them your design. You just have to process it > with their software, right? If all else fails, you can do that on a > machine that is not connected anywhere and wipe the disk once you have > taken your data with you. That should make even the CIA happy... well > maybe not the CIA. They would want to reverse engineer the code and > destroy the hard drive along with any non-volatile memory. > > Jim, > > > > The Atmel devices top out at 128 macrocells, but you can pack > > > a little more into a Atmel macrocell. > > > The new BE family, are uA static devices, in 32/64 MC (released) > > > and 128MC (soon) > > I guess these are new devices that weren't out when I looked. Are > they planning anything larger than 128 macrocells? Personally I like > the Lattice parts. They also have some interesting flash FPGA like > devices, but of course they are not zero power. > > > > The Lattice ispMACH4000 family go to 256MC in Zero power, and > > > 512 in non-zero power. (IIRC) > > > > In the larger 128/512 macrocell area, CPLDs struggle a little, > > > and the FPGA Fabric CPLDs are taking over (Altere MAX II, > > > lattice MachXO, and the Actel Igloo devices are examples. > > > Igloo are relatively new, but I saw a press release claiming > > > $1.50[volume] for ~192 macrocell equiv device. > > I'm not sure why you say CPLDs are "taking over". 512 macrocell > devices have been around for quite some time. Actually, I think the > Lattice XO flash based FPGA parts are doing a good job of pushing > down, along with the MAX II parts which are FPGA like. Just because > they have flash, does not make them CPLDs in my opinion. These lines > are LUT based and route like FPGAs. I think that makes them much more > usable for the high end of CPLDs, not to mention cheaper! > > > > Lattice do have a 'sort-of' 5V spec: they say 5.5V max, but > > > add this strange qualifier : > > > "5. Maximum of 64 I/Os per device with VIN > 3.6V is allowed." > > > [How does one IO, know, or care, what the voltage is on another IO ?] > > I asked about this once and they told me it has to do with the leakage > current. You can drive the I/Os above Vdd, but it will draw more > current. Too many at one time and the device can blow. Not totally > unlike multiple I/Os driving LEDs and such. But you can ask your > FAE.Article: 126329
Here is the comment by Jesse Jenkins, who was and is responsible for CPLD applications support: ...regarding the JEDEC issue. We do NOT want people making their own programming solutions. When we engage with third party programmer manufacturers, we have them go through extensive qualification of their circuitry, sign NDAs, etc. to assure they are doing a great job of programming our parts. It's more complicated than just delivering a bitstream into the parts. Internal charge pump voltage levels, various pulse widths, etc must be correctly delivered to assure correctly programmed parts. If these parameters are violated, parts can be incorrectly programmed, and create huge customer support issues. We wish to avoid these. It increases the cost of supporting the parts for our main stream customers that are willing to use our recommended methods, and CPLDs are a very competitive market. Will you please kindly convey this to the Comp Arch folks? Thanks, JJ Submitted by Peter Alfke, Xilinx Applications On Nov 19, 3:03 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > >>The Atmel devices top out at 128 macrocells, but you can pack > >>a little more into a Atmel macrocell. > >>The new BE family, are uA static devices, in 32/64 MC (released) > >>and 128MC (soon) > > > Well the fact of the matter is that there is no CPLD on the market > > to compete with all the coolrunner parameters at the same time - and > > I do use them. > > Across the size range, you may be right. > But at the highest volume end Atmel and Lattice have good low power > offerings. Actel may start to impact > 128MC CPLDs > > > Philips could have taken over the sector with that device easily, > > we'll never know what happened behind the scenes so they sold it to > > xilinx - who immediately killed the original Philips line which was > > great but had leaked out programming information (no other plausible > > reason for killing such a good device I can think of). > > My understanding there is the parts were not externally foundry fab'd > and when the plug was pulled on the fab line, that then killed the > product line. (similar problem happened with some Lattice.AMD parts) > > Not good for the end customers. - but certainly not a conspiracy, > instead a by-product of some decoupled bean-counter's decisons, and > we have all seen that before ! :) > > > And now we stand with xilinx having monopoly over the only up-to-date > > CPLD on the market, and they will not let you write to it without > > revealing your written code to them (oh yeah, they'll swear to god > > their software only translates one map to another and I am just > > paranoid because I think it is the spyware it actually is - but > > ask them _why_ do they keep that jedec -> jtag mapping data secret > > and feel free to wait for another century for a plausible answer). > > That is a good question. > > Comments Austin ? ( or Jesse? ) > > -jgArticle: 126330
rickman wrote: <snip> >>Well the fact of the matter is that there is no CPLD on the market >>to compete with all the coolrunner parameters at the same time - and >>I do use them. > > > I feel your pain. It is often that I need devices with 5 volt > tolerance. But that makes it difficult to migrate to the finer > processes which lower the cost of devices. Adding extra processing to > retain 5 volt tolerance drives the price back up. I can't say which > of the two is more significant, but it is interesting that many MCU > vendors seem able to produce 5 volt tolerant devices in the newer > processes at *VERY low* prices. I do mention this to the CPLD vendors, but part of the constraint, is the CPLD market is relatively small, and the design teams tend to be digital in nature, so they let the process dictate Vcc, and not be proactive about the other way around. Some of it is related to Test flow, and guarantees. eg I have tested the ATF1502BE, for example, and it has a nice open-drain (no VccIO clamp diode) ESD structure that avalanches at 5.6V This has a 2KV ESD rating, so it is quite a rugged avalanch. So, from a simple test bench aspect there seems to be no reason to not spec this as a 5V tolerant device. But if the process and oxide are not qualified to do that, Atmel are reluctant to spec it. As an example from the processor sector, I'm impressed by the Freescle RS08. 30c+ region prices, and 'hidden' on-chip regulator, for stable uA level operation, and Vcc from 1.8 to 5.5V A CPLD in that process, would be a nice device :) > Jim, > > >>>The Atmel devices top out at 128 macrocells, but you can pack >>>a little more into a Atmel macrocell. >>>The new BE family, are uA static devices, in 32/64 MC (released) >>>and 128MC (soon) > > > I guess these are new devices that weren't out when I looked. Are > they planning anything larger than 128 macrocells? The road map is hazy there. A part number exists, but I'm not sure a schedule does :) In these bigger CPLDs it gets harder to compete with the fpga-fabric alternatives, like the Igloo. There is a single supply 128 MC device coming (ATF1508RE-7AU100), with a better regulator than Lattice. (but not as good as the RS08 :) > Personally I like > the Lattice parts. They also have some interesting flash FPGA like > devices, but of course they are not zero power. > > > >>>The Lattice ispMACH4000 family go to 256MC in Zero power, and >>>512 in non-zero power. (IIRC) >> >>>In the larger 128/512 macrocell area, CPLDs struggle a little, >>>and the FPGA Fabric CPLDs are taking over (Altere MAX II, >>>lattice MachXO, and the Actel Igloo devices are examples. >>>Igloo are relatively new, but I saw a press release claiming >>>$1.50[volume] for ~192 macrocell equiv device. > > > I'm not sure why you say CPLDs are "taking over". 512 macrocell > devices have been around for quite some time. Actually, I think the > Lattice XO flash based FPGA parts are doing a good job of pushing > down, along with the MAX II parts which are FPGA like. Just because > they have flash, does not make them CPLDs in my opinion. These lines > are LUT based and route like FPGAs. I think that makes them much more > usable for the high end of CPLDs, not to mention cheaper! I think you misread what I wrote. I said at the larger CPLD spectrum the 'FPGA Fabric' CPLDs are taking over. You may not call them CPLDs but they are marketed as CPLDs. They are cheaper, because in the large sizes, CPLDs do not scale well. >>>Lattice do have a 'sort-of' 5V spec: they say 5.5V max, but >>>add this strange qualifier : >>>"5. Maximum of 64 I/Os per device with VIN > 3.6V is allowed." >>>[How does one IO, know, or care, what the voltage is on another IO ?] > > > I asked about this once and they told me it has to do with the leakage > current. You can drive the I/Os above Vdd, but it will draw more > current. Too many at one time and the device can blow. Not totally > unlike multiple I/Os driving LEDs and such. But you can ask your > FAE. Yes, but the data quotes 20uA MAX at 105'C, for a pin at 5.5V Does not look like a big thermal issue to me :) -jgArticle: 126331
Hi Peter, thanks for forwarding the message to the group. > ...regarding the JEDEC issue. We do NOT want people making their own > programming solutions. When we engage with third party programmer > manufacturers, we have them go through extensive qualification of > their circuitry, sign NDAs, etc. to assure they are doing a great job > of programming our parts. It's more complicated than just delivering > a bitstream into the parts. Internal charge pump voltage levels, > various pulse widths, etc must be correctly delivered to assure > correctly programmed parts. If these parameters are violated, parts > can be incorrectly programmed, So XAPP058 is not viable after all. The above quote states that reprogramming of a xilinx coolrunner CPLD is not possible in a stand-alone system to which no cable is attached and is done by some local MCU - say, remotely. Now perhaps Xilinx CPLD support would consider commenting on which we are supposed to believe - xapp058 or the above statement. > and create huge customer > support issues. We wish to avoid these. It increases the cost of > supporting the parts for our main stream customers that are willing to > use our recommended methods, and CPLDs are a very competitive market. This is simply not true. Like anyone else, Xilinx can provide support only to those using their tools and let the rest of us use ours without support, just hand us the jedec -> jtag data. BTW, the sequences and timings are all publically available anyway from xilinx; it is only the Excel mapping files which are kept secret. I would sign what it takes to gain access to them, including a guarantee not to ask any support questions (i.e. if I have the true data and things do not work for me, I'll accept that). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 2:09 am, Peter Alfke <pe...@xilinx.com> wrote: > Here is the comment by Jesse Jenkins, who was and is responsible for > CPLD applications support: > > ...regarding the JEDEC issue. We do NOT want people making their own > programming solutions. When we engage with third party programmer > manufacturers, we have them go through extensive qualification of > their circuitry, sign NDAs, etc. to assure they are doing a great job > of programming our parts. It's more complicated than just delivering > a bitstream into the parts. Internal charge pump voltage levels, > various pulse widths, etc must be correctly delivered to assure > correctly programmed parts. If these parameters are violated, parts > can be incorrectly programmed, and create huge customer > support issues. We wish to avoid these. It increases the cost of > supporting the parts for our main stream customers that are willing to > use our recommended methods, and CPLDs are a very competitive market. > > Will you please kindly convey this to the Comp Arch folks? > Thanks, > JJ > Submitted by Peter Alfke, Xilinx Applications > > On Nov 19, 3:03 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > > > Didi wrote: > > >>The Atmel devices top out at 128 macrocells, but you can pack > > >>a little more into a Atmel macrocell. > > >>The new BE family, are uA static devices, in 32/64 MC (released) > > >>and 128MC (soon) > > > > Well the fact of the matter is that there is no CPLD on the market > > > to compete with all the coolrunner parameters at the same time - and > > > I do use them. > > > Across the size range, you may be right. > > But at the highest volume end Atmel and Lattice have good low power > > offerings. Actel may start to impact > 128MC CPLDs > > > > Philips could have taken over the sector with that device easily, > > > we'll never know what happened behind the scenes so they sold it to > > > xilinx - who immediately killed the original Philips line which was > > > great but had leaked out programming information (no other plausible > > > reason for killing such a good device I can think of). > > > My understanding there is the parts were not externally foundry fab'd > > and when the plug was pulled on the fab line, that then killed the > > product line. (similar problem happened with some Lattice.AMD parts) > > > Not good for the end customers. - but certainly not a conspiracy, > > instead a by-product of some decoupled bean-counter's decisons, and > > we have all seen that before ! :) > > > > And now we stand with xilinx having monopoly over the only up-to-date > > > CPLD on the market, and they will not let you write to it without > > > revealing your written code to them (oh yeah, they'll swear to god > > > their software only translates one map to another and I am just > > > paranoid because I think it is the spyware it actually is - but > > > ask them _why_ do they keep that jedec -> jtag mapping data secret > > > and feel free to wait for another century for a plausible answer). > > > That is a good question. > > > Comments Austin ? ( or Jesse? ) > > > -jgArticle: 126332
u_stadler@yahoo.de wrote: > ... > entity spi_memory is > PORT ( CLK : in STD_LOGIC; > Data_in : inout STD_LOGIC_VECTOR (31 downto 0); > ... I just noticed that. Could you explain why Data_in is inout? If you are going to do that, then a driver is expected somewhere within this code. And if you don't supply a driver, perhaps a 'U' is inferred. Normally an inout port would be driven with a piece of code that looks something like: Data_in <= Data_inout when DEN = '1' else "ZZZZ...";Article: 126333
Peter Alfke wrote: > Here is the comment by Jesse Jenkins, who was and is responsible for > CPLD applications support: > > ...regarding the JEDEC issue. We do NOT want people making their own > programming solutions. When we engage with third party programmer > manufacturers, we have them go through extensive qualification of > their circuitry, sign NDAs, etc. to assure they are doing a great job > of programming our parts. It's more complicated than just delivering > a bitstream into the parts. Internal charge pump voltage levels, > various pulse widths, etc must be correctly delivered to assure > correctly programmed parts. If these parameters are violated, parts > can be incorrectly programmed, and create huge customer > support issues. We wish to avoid these. It increases the cost of > supporting the parts for our main stream customers that are willing to > use our recommended methods, and CPLDs are a very competitive market. > > Will you please kindly convey this to the Comp Arch folks? > Thanks, > JJ > Submitted by Peter Alfke, Xilinx Applications Thanks Peter / Jesse. I can sort of understand the reasoning, but how does this reconcile with Antonio's post : > In last project I did I had to program (or re-program) a CoolrunnerII (XC2C256) by JTAG with a microcontroller. Xilinx provides all the info you need in their app notes. > > It was not so difficult; in fact, it works so well I'm using that also on production. Just a second to program a XC2C256, reasonably filled. > > 1) Tweak the XAPP058 code for your platform; easy, that code is meant to be "easily" ported. Seems Antonio DID 'make his own programming solution', in a microcontroller ? JTAG is a purely digital interface. -jgArticle: 126334
ghelbig@lycos.com wrote: > > Except for crt0.s, there really isn't a need for assembly programming > a RISC processor... In general I agree, but in addition to crt0.s, I find assy language is often very useful for memcpy/blitting/bulk IO operations in embedded systems. -JeffArticle: 126335
In article <19c9df45-da86-46c4-abb4-ee94a4aedc8a@e25g2000prg.googlegroups.com>, Peter Alfke <peter@xilinx.com> writes: >Here is the comment by Jesse Jenkins, who was and is responsible for >CPLD applications support: > >...regarding the JEDEC issue. We do NOT want people making their own >programming solutions. When we engage with third party programmer >manufacturers, we have them go through extensive qualification of >their circuitry, sign NDAs, etc. to assure they are doing a great job >of programming our parts. It's more complicated than just delivering >a bitstream into the parts. Internal charge pump voltage levels, >various pulse widths, etc must be correctly delivered to assure >correctly programmed parts. If these parameters are violated, parts >can be incorrectly programmed, and create huge customer >support issues. We wish to avoid these. It increases the cost of >supporting the parts for our main stream customers that are willing to >use our recommended methods, and CPLDs are a very competitive market. 30 years ago, back in the dark ages when programming algorithims were mostly analog black magic, that sort of story would have made sense. Is that still valid today? I thought programming via JTAG was now common. I think of JTAG as a digital process. Are there weird timing restrictions that a typical programmer gets wrong? I assume most of your CPLDs are programmed by some ATE gear connected to the JTAG pins. Who writes the "program" that does that? Is there a certified subroutine that the end user calls to program a CPLD? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 126336
Hal Murray wrote: > In article <19c9df45-da86-46c4-abb4-ee94a4aedc8a@e25g2000prg.googlegroups.com>, Peter Alfke <peter@xilinx.com> writes: > >>Here is the comment by Jesse Jenkins, who was and is responsible for >>CPLD applications support: >> >>...regarding the JEDEC issue. We do NOT want people making their own >>programming solutions. When we engage with third party programmer >>manufacturers, we have them go through extensive qualification of >>their circuitry, sign NDAs, etc. to assure they are doing a great job >>of programming our parts. It's more complicated than just delivering >>a bitstream into the parts. Internal charge pump voltage levels, >>various pulse widths, etc must be correctly delivered to assure >>correctly programmed parts. If these parameters are violated, parts >>can be incorrectly programmed, and create huge customer >>support issues. We wish to avoid these. It increases the cost of >>supporting the parts for our main stream customers that are willing to >>use our recommended methods, and CPLDs are a very competitive market. > > > 30 years ago, back in the dark ages when programming algorithims > were mostly analog black magic, that sort of story would have made sense. Yes, I recall seeing dV/dT specs on some fuse devices > Is that still valid today? I thought programming via JTAG was > now common. it is more than common, on many device that is the ONLY means of programming. > I think of JTAG as a digital process. Are there > weird timing restrictions that a typical programmer gets wrong? No. JTAG does not even cycle Vcc. The most complex timing, is the JTAG link itself. > > I assume most of your CPLDs are programmed by some ATE gear > connected to the JTAG pins. Who writes the "program" that does > that? Is there a certified subroutine that the end user calls > to program a CPLD? Some use SVF files. Most EE/FLASH chips self-time, and you'll see things like : PowerUp time [1ms] Bulk Erase time [<950ms ] Write time [<5ms] So about the only rocket science, is a simple timer. These things can be programmed from parallel port cables, and the times above are not even bounded, just simple 'wait longer than' A few devices have dual-purpose JTAG pins, and they have some means to unlock the JTAG access. - but that's only needed if you want dual mode pins. -jgArticle: 126337
On Nov 19, 7:43 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > rickman wrote: > > I think you misread what I wrote. I said at the larger CPLD spectrum > the 'FPGA Fabric' CPLDs are taking over. You may not call them CPLDs > but they are marketed as CPLDs. > They are cheaper, because in the large sizes, CPLDs do not scale well. Yes, I see now that we are saying the same thing. I agree that the FPGA fabric is likely cheaper as well as more versatile. If you need a simple and gate to drive an output, it uses a full macro cell in a CPLD. Using a LUT is a lot less expensive for smaller logic functions. > > I asked about this once and they told me it has to do with the leakage > > current. You can drive the I/Os above Vdd, but it will draw more > > current. Too many at one time and the device can blow. Not totally > > unlike multiple I/Os driving LEDs and such. But you can ask your > > FAE. > > Yes, but the data quotes 20uA MAX at 105'C, for a pin at 5.5V > Does not look like a big thermal issue to me :) I don't think it is a thermal issue. I did not get a full explanation, but I believe then since they would have no reason to spec that limit if it wasn't real. Like I said, you might try asking your FAE what the basis of that limitation is.Article: 126338
Il 20/11/2007 0.06, Didi ha scritto: > >> 3) use Impact (free download) to translate the jedec in a XSVF binary >> file. You can do on GUI by hand, or by makefile as I prefer; syntax is: >> > > Now this is a hoop I can do without. XAPP058 actually states you have > to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely > available. Is the tool for doing jedec->svf also freely available? > Can you point me to it please? > Impact makes the jedec -> svf OR jedec ->XSVF translation, with the commands of my previous posts. At the time of XAPP058, it wasn't able to. Now you can just go stright from jedec to XSVF with Impact alone. Impact is free with the Webpack (http://www.xilinx.com/ise/logic_design_prod/webpack.htm). (I remember that there's also a "production" package with just the Impact tool, but I don't find the link).Article: 126339
Il 20/11/2007 0.06, Jim Granville ha scritto: > > That is also a good suggestion. > What code/data size was the microcontroller 'SVF/Jatg player' ? > In one case, a Renesas r8c/tiny (16k flash, 1 kram), programming a X2C64. The CPLD binary content was "pulled" from the jtag player by an RS485 connection. In another, a Blackfin BF561 with lots of memory, programming a X2C256, directly. In the R8C/Tiny case, the player needs roughly 3-4Kb of code and 600-700 bytes of ram (most of them are temporary buffers, you can "recycle" for other purposes out of the programming routines).Article: 126340
On Nov 19, 4:46 pm, xenix <last...@gmail.com> wrote: > hello all, > I am looking for some books for microblaze and some examples with > assembly for microblaze. since now i havent found anything helpful. > thank you > > regards You can find some useful information in my blog: http://www.fpgafromscratch.com SvenArticle: 126341
I have created a custom peripheral in EDK 9.1/ISE 9.1 that needs to have 100 registers and communicates with the PowerPC CPU via the PLB bus. The board I'm using is the XUP Virtex-IIPro dev. board. I used the wizard in EDK to create a template for my peripheral, but the wizard only offers up to 32 registers. Therefore, I selected 32 registers and tried to change the USER_NUM_CE constant in the top-level module in the created template to 128, as opposed to 32. I have read the PLB IPIF datasheet from Xilinx, which only says that USER_NUM_CE needs to be a power of two, which is why I used 128 versus 100. After implementation, access to any register above 32 leads to a returned value of zero, when it should be non-zero. Any suggestions of what else I need to change in the generated IPIF code to get this working? I really would like to avoid rolling my own. ---Matthew HicksArticle: 126342
Wow, how a discussion can evolve from a single reply from Austin to contact my disti to a discussion about the distribution landscape in Europe. At Austin I would like to say: Austin, I've contacted my disti, but they don't carry Xilinx. I'm sorry, I'm a Lattice user, so if I would concider Xilinx (or Altera) the disti should contact me, shouldn't they? At all they other posters in this discussion: yes, you are right, distribution has changed, but I wouldn't generalize this statement. There are still good FAE's in this world. But the supplier should train them well, and let them do their job, get experienced, find the best solution (even if this is not in line with the directives from the supplier to sell the newest part), ... Concider this statement: distribution FAE's are the sausage between the hot dog. They are sitting between the supplier and the customer and are also trying to do what they are payed for. At the end, I haven't found out the latest and greatest from Xilinx - and as long as the parts aren't available in production, I will not concider them for a new design. The ECP2M that I'm using is in production, I get my parts at a decent price (better than the "one off" price at Digikey), and I get from time to time annoying questions from the disti FAE. But that's life I guess. (refering to Austin) At least, I'm happy that my design is working. Now I can look for someone who can build it in smaller quantities. But that's another discussion, isn't it? Luc On Mon, 19 Nov 2007 18:24:03 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Mon, 19 Nov 2007 10:00:22 -0800, austin <austin@xilinx.com> wrote: > >>If one argues that FPGA technology needs to become more user friendly, >>and easier to use, in order to make inroads into all possible >>applications, your experience is merely one example of an opportunity >>(for Xilinx). > >Please don't forget that the experiences I was reporting >(ranting about) are a decade old. To a large extent I think >it's an opportunity you've already grasped - webshop, >excellent online documentation, free software downloads >for smaller customers, good appnotes.... and, dare I say, >informal access to top-notch factory expertise via public >media such as this group. > >>Sure, we could say "well, that is life" but who would we be serving? > >Nah. You wouldn't do that. You need to eat too :-) > >Like I said: it seems to me that major FPGA vendors have somewhat >taken that opportunity already. Almost without exception, they >(or at least their FPGA business) started small, with reasonably >close relations between factory and even the smaller customers. >As they've grown they seem to have remembered that heritage, >and the quality of technical information available through >FPGA vendors' websites and other resources is pretty good. >(Yes, I know people complain all the time. And you put a >brave face on it, because you know that there's at least a >grain of truth in most complaints, and you want happy customers >and happy potential customers. We appreciate it. Really.) > >I see the result of all this being a sidelining of the traditional >distributor role as intermediary between factory and customer. >Instead, the successful distributors either act as supermarkets >(in which case let us treat them as such, and punish with our >lack of custom those who can't keep their shelves full of >attractive products at attractive prices) or act as agencies >helping large customers collaborate effectively with the >factory to ensure a good deal for both parties. The >traditional component disti, who tries to erect walls between >customer and factory to protect his own revenue monopoly >at the customer's expense, is surely a dinosaur whose >meteorite is already bright in the sky. Their passing >will be mourned by but few.Article: 126343
Hi all, I'm experiencing problems with adding custom logic to an IP core that I have generate in EDK. I changed the vhdl file of an auto- generated IP core that is connected via FSL to the FPGA, but the behaviour of the program remains still the same. I've tried also to re- import the modified core to the project, but I still get errors due to the fact that the file xparameters.h doesn't contains the appropriated names. How can I do to let EDK notice changes in vhdl files? Thank you in advance! GiulioArticle: 126344
techG wrote: > Hi all, I'm experiencing problems with adding custom logic to an IP > core that I have generate in EDK. I changed the vhdl file of an auto- > generated IP core that is connected via FSL to the FPGA, but the > behaviour of the program remains still the same. I've tried also to re- > import the modified core to the project, but I still get errors due to > the fact that the file xparameters.h doesn't contains the appropriated > names. > How can I do to let EDK notice changes in vhdl files? > Thank you in advance! > > Giulio Hi Giulio, You can regenerate the xparameters.h file using this menu option: Software -> Generate Libraries and BSPs AndyArticle: 126345
Hi all, i'm currently trying to make an virtex2 project with edk 9.2i. Unfortunately all virtex2 based boards are removed from the bsb dialog (also boards with older spartan devices). Also the migration of an existing edk 91.i virtex2 project doesn't work. The reason for these should be the new plb_v4.6. But the old plb version is still there, so it should work. Any ideas to solve these problem ? Thanks in advance ! AndreasArticle: 126346
Antonio Pasini wrote: > Il 20/11/2007 0.06, Didi ha scritto: > >> >>> 3) use Impact (free download) to translate the jedec in a XSVF binary >>> file. You can do on GUI by hand, or by makefile as I prefer; syntax is: >>> >> >> Now this is a hoop I can do without. XAPP058 actually states you have >> to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely >> available. Is the tool for doing jedec->svf also freely available? >> Can you point me to it please? >> > > Impact makes the jedec -> svf OR jedec ->XSVF translation, with the > commands of my previous posts. > At the time of XAPP058, it wasn't able to. > Now you can just go stright from jedec to XSVF with Impact alone. > > Impact is free with the Webpack > (http://www.xilinx.com/ise/logic_design_prod/webpack.htm). > > (I remember that there's also a "production" package with just the > Impact tool, but I don't find the link). Do you have the xsvf file size handy, for your XC2C64 design ? That would give Didi some info on the svf pathway. (to go with the player info you've given) (the XC2C64 has 3226.5 Bytes of fuse info.) Usually svf have quite an overhead : (eg an Atmel device with 2101.75 bytes of fuse info, spawns a 110925 byte SVF file ~ 50:1 ) I have not tried to compress the SVF, but I'd guess 5-10 simple compression should be easy, esp for a known brand. So that brings it down to 10-20K bytes, for a 2K binary image. I also notice the Atmel tools can create a PCF via SVF2PCF, for an even larger file, but one that is a logic analyser storage - 191K lines, to JED pgm the 2KB fuses. -jgArticle: 126347
Harald schrieb: > Sounds good, I just have here a full version of 7.1 available. > So everyone would recommend me to download the 9.2 webpackage version > and install that instead of 7.1? That depends if your device is supported by WebPack. Take a look at http://www.xilinx.com/ise/products/webpack_config.htm Regards, AndreasArticle: 126348
> i'm currently trying to make an virtex2 project with edk 9.2i. > Unfortunately all virtex2 based boards are removed from the bsb dialog > (also boards with older spartan devices). I have the same problem. I have a Virtex2-XC2V6000 board that I wanna use for sythesis. In the device properties of ISE 9.2 I just have the option to chose between the following devices: - XC2V40 - XC2V80 - XC2V250 - XC2V500 Is there a way to run synthesis for my board? I assume the other boards wont be compatible with the one I am using? Cheers, HaraldArticle: 126349
Dear Harald, i have in the ISE9.2_03i(lin64) the xc2v6000 in the device option tab my problem is the edk and not the ise Regards, Andreas Harald wrote: >> i'm currently trying to make an virtex2 project with edk 9.2i. >> Unfortunately all virtex2 based boards are removed from the bsb dialog >> (also boards with older spartan devices). > > I have the same problem. I have a Virtex2-XC2V6000 board that I wanna > use for sythesis. In the device properties of ISE 9.2 I just have the > option to chose between the following devices: > > - XC2V40 > - XC2V80 > - XC2V250 > - XC2V500 > > Is there a way to run synthesis for my board? I assume the other boards > wont be compatible with the one I am using? > > Cheers, > Harald
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