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
gabor wrote: (snip) > For Spartan 3 MIG, which is primitive compared to the Virtex 5 > MIG, the order of row vs. bank addressing is not important. > This is due to the fact that the MIG code only leaves one > row of one bank active at any time. The column address should > be your low order address bits for linear addressing. This > will prevent unnecessary row precharge / activate sequences > when performing linear access to memory. One that I might try is a video display that also refreshes the RAM. That is an old trick that might still work. > Also note that > the least significant bits of the column address are > incremented inside the memory chip during a burst operation. > There is no carry out to the upper address bits, so when > starting a burst you should normally begin at a burst > boundary to avoid rapping back to previous addresses. I don't expect any burst operations. My first system will be 8080 based, and I don't believe that the 8080 does bursts. > Be careful when using the MIG top level interface with > "linear" address. It may be using the least significant > bits for the bank address (depends on which interface > type DDR, DDR2, etc.). -- glenArticle: 138551
On Feb 26, 10:56=A0am, mansoor.nas...@gmail.com wrote: > On Feb 25, 11:15=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > On Feb 23, 4:49=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > On Feb 23, 12:42=A0pm, Dave Pollum <vze24...@verizon.net> wrote: > > > > > On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > Hi, > > > > > It is intersting to find that $24.50 is for an Altera ByteBlast > > > > > programmer mentioned in a topics in FPGA group. > > > > > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500= chip > > > > > only. > > > > > > Please give any tips where I can buy a cheap programmer. > > > > > > Thank you. > > > > > > Weng > > > > > Digilent (digilentinc.com) has inexpensive programming cables. > > > > -Dave Pollum > > > > Hi Dave, > > > Good information! I need cables too. But hopefully I may get a set of > > > programmer plus its cables from one person or a company. > > > > Weng- Hide quoted text - > > > > - Show quoted text - > > > Hi Dave, > > I checked Digilent.com website and I am not sure which one works for > > my system: Xilinx Virtext II XC2V 1000. > > > JTAG Programming Cable $12.00 > > low-cost JTAG configuration solution > > for use with any JTAG-programmable device > > connects directly to the parallel port of a PC, and to a standard 6- > > pin JTAG programming header > > can program devices that have a JTAG voltage of 1.8V or greater > > > I found my board has a 14-pin connector, but above specs says it has a > > 6-pin JTAG programming header. Is it fit? > > > Is Xilinx iMPACT software still usable? > > > Please give me a help to determine if which is fit. > > > Thank you. > > > Weng > > software still usable, go for jtag usb programming cable (37.95$), it > will be faster > it works with impact software > for jtag the most important six connections are VCC, GND, TMS, TDI, > TDO, TCK > the 14 pin connector repeats some of the pins but effectively these > six pins are required to program xilinx fpgas. > You can make a manual adaptor with 6 Pin MTE Cable (also on the same > page) which will break individual signal (TMS, TCK etc) into wires > > hope this helps > > mak- Hide quoted text - > > - Show quoted text - Hi Mak, Your comments are very instructive and helpful. Another question: Can JTAG USB programming capable be used together with Xilinx ChipScope? I think if IMPACT works with the cable, ChipScope should work too, is it true? Thank you. WengArticle: 138552
Inside dma_ddr2_if.v,i noticed the bottom 5 lsb all zero of ingress_start_addr/egress_start_addr[27:6] . Why? is it PCIE or DDR2 requirement? How should i provide DDR2 address?Article: 138553
On Feb 26, 1:03=A0am, srikanthv2 <srikant...@gmail.com> wrote: > Hello, > I am working on a project where I have a chip that produces serial > data. This data is to be sent to the PC via the USB, through an FPGA. > I was wondering if the UFO-400 (Open FPGA project) board is the ideal > choice as a prototype board. > > I wanted to look through examples from various vendors but only the > open source project has code available (duh!) > > My considerations are the following things: > > 1. FPGA programming (all boards use standard Xilinx/Altera FPGAs. so > this is not a problem) > 2. Software interface on the PC - to not only program the FPGA but > also to talk to the FPGA after programming. (I presume the vendors > will provide this, I am concerned about the availability of the source > code in case I want to =A0modify this to suit my custom board) > > 3. USB controller firmware (Again, will I need to edit the firmware? > If yes, would the open source project be the ideal choice?) > > any help is appreciated. Thanks! > > Srikanth The Avnet Spartan-3A kit has the USB chip set up by default to provide a 115.2 kbaud virtual serial port to the FPGA. If that's all you need, then it could be a quick way to get started with your project.Article: 138554
rickman wrote: > When you refer to "high end" processors, you are talking about a > literal handful of devices compared to the hundreds or thousands of > types of CPUs that are used in embedded systems. If you are talking I'm referring to chips like Intel atom, new PowerQuicc IIP/III processors etc. They usually have few PCIe ports as a default and if they are not enough a switch is needed. And I don't see why low end would not adopt PCIe. Each saved pin helps to get into a smaller and cheaper package (altough wirebond and PCIe frequencies might be challenging). > about adding a "switch" then you are adding an extra chip and you can > just as easily add any sort of chip to facilitate booting the FPGA. The problem is that there are only few vendors for special bridge chips to GPIO etc. But for PCIe switches there are many vendors even some with identical pinouts. That helps multisourcing for manufacturing. Also Industrial temperature requirements narrow down the choices. > I'm not familar with PCIe, but I know in PCI apps you can't use the > PCI interface to boot the FPGA. Are you talking about an embedded app You could use it, if there would be FPGA on the market with hardcore IP for PCI and someone would have thought of using it for configuration at FPGA vendor. But that would have required too many pins etc. to be a good and widely used solution. > where you can work "around" the PCIe spec and just talk to the FPGA > without worrying about the spec'd protocol? In that case you have one I'm thinking that if you have hardcore IP for PCIe then it can immediatly answer to the bus even if the FPGA is not loaded. If the PCI configuration space would then have extended configuration register that could be used to bang the data in via configuration cycles. Or other option would be one hardcoded PCI BAR for the configuration image. Memory mapped configuration image also might create some pretty interesting opportunities for dynamic reconfiguration. > of the few apps where your PCIe port is dedicated to the FPGA. Yes, > in that case this works. But that is rare enough that the FPGA > vendors aren't going to add that capability for those few apps. With hardcore it can be done in a standard way, altough the boot code needs some changes. And SIVGX, V5LXT, V5FXT, V6, S6, ArriaIIGX at least have PCIe hardcore already. They just haven't built the configuration interface yet (or they might have, but are not documenting it). There are usually undocumented features in FPGAs that are just not enabled, and might be enabled for few customers with custom IP for testing. > I seem to recall that there was support for a JTAG or some other > serial interface on PCI, but it has been so long that I don't recall. I think you are referring to SMBus. It is I2C style slow (10kHz-100kHz) interface. I think it would be too slow for FPGA configuration. --KimArticle: 138555
Hal Murray schrieb: >> but, well microblaze is WRONG endian it just makes >> lots of trouble > > It should be simple to make a RIGHT endian version > of microblaze. It's probably just a few lines of text. > The PowerPC405/440 core in the Virtex devices has it's own instruction to do little endian/big endian conversion. Also you can mark memory pages as little endian/big endian. -MarkusArticle: 138556
Hi time is flying fast so only a few days til embedded world.. I just got about 1100 pcs of UDcard spi flash PCB's that are really nice to use for FPGA configuration for give away at embedded world (giveaway is for empty PCB only) http://www.udcard.org/ this board as pictured can be assembled with max 4MByte Atmel Dataflash 4Mbyte is sufficient for many FPGA's I will be most of the time in Hall 12, booth 12-536 I do not know how long the 1100 pcs to give away will last, but i will try to keep little secret stock :) AnttiArticle: 138557
> 1. FPGA programming (all boards use standard Xilinx/Altera FPGAs. so > this is not a problem) FPGA can be programmed through the USB. There is an interface through Python or C/C++ to send a bitfile. > 2. Software interface on the PC - to not only program the FPGA but > also to talk to the FPGA after programming. (I presume the vendors > will provide this, I am concerned about the availability of the source > code in case I want to =A0modify this to suit my custom board) Yes, all the source code is available. You can browse the source code on sourceforge. > 3. USB controller firmware (Again, will I need to edit the firmware? > If yes, would the open source project be the ideal choice?) You will not need to edit the FX2 (USB controller) firmware. The firmware that is available you can use it as a virtual serial port or direct bulk transfers. From python or C/C++ code you can easily, program the FPGA, read/write data. All the source is available for the PC, USB controller, and FPGA. The UFO-400 can be used for simple interface or high speed transfers. The FTDI based boards are good as well, these chips are usually used on boards as a way to quickly add a USB interface. My experience with the FTDI chips, only useful for slow rates and not as flexible. You need to use the FTDI binary drivers, etc. The FTDI chips first claim to fame was to allow a designers to add USB to a board and there chip would convert USB stream to a standard serial (RS-232). You would use a virtual com port on the PC. But flexibility can be a pain in some case. If you decided to modify the source you can get bogged down in the details. But the source that is available removes any up front work that would need to be done. You can use it out of the box.Article: 138558
Dave wrote: > Try this - it isn't guaranteed to be the same encoding as the > synthesizer will use, but it will give you the state represented by a > SLV: > > library ieee; > use ieee.std_logic_1164.all; > use ieee.numeric_std.all; > > type state_type is (IDLE, STATE1, STATE2, ...); > signal state : state_type; > signal state_slv : std_logic_vector(num_bits-1 downto 0); > > ... > > state_slv <= std_logic_vector(to_unsigned(state_type'pos(state), > num_bits)); > > This should give you the state number, starting from zero and in the > same order as they are declared the the type definition. > > Dave > A potential problem here is that since the type of state encoding is unknown - binary, one-hot, ??? - the value of num_bits is not known unless one looks at the synthesis report -UrbArticle: 138559
On Feb 25, 9:51=A0am, colin <colin_toog...@yahoo.com> wrote: > Hello > > I have a new virtex 5 design with a lot of IO going at the same speed. > I've been told to put all this IO on the same column. Also I can then > use the DCI bank cascading. > > Does anyone know the logic behind the bank numbering? I can't find any > data on which banks are in which column. > > Colin PlanAhead can show you where the IO banks are internally. I wouldn't be surprised if you could do it with the FPGA editor too, but I haven't tried. ChrisArticle: 138560
Antti skrev: > Hi > > it has nothing todo with Basic Stamps, just the PCB looks like a > stamp, hence the name > > http://www.trioflex.com/files/Stamp60-UM.pdf > > preliminary user manual is now online. The first stamp is based on > Actel FPGA > and well the user manual maybe some interesting reading - for me it > was surprise > how nice actel tools have become (compared to what they used to be). > > it is also interesting that Actel ist the only company offering small > customizeable > Soft-Core fully integrated with their IDE. PicoBlaze is still not > fully officially supported > and probably never will be integrated to Xilinx IDE. > > Antti > PS if some is interested i should have some give away units of the > stamp > at Embedded World. meeting at 12-536 Does it include an envelope... ?? :-) Anway, IF one had the time, one could sit down a wrap the picoblaze as an IP core, add some BRAM interface block, define bus cores, picoblaze to PLB bus bridge and other stuff nedded. That would make it easier to hook it up to whatever core you have made that needs it - or for a standalone system (type Atmel AVR and PIC systems). Updating the BRAM with application code could be done with some perl/tcl scripts. But integration of a debugger/simulator for it would be a difficult but very usefull thing. Xilinx should put one person on doing that job. Or perhaps the author of it would be keen on doing it. Kenn are you reading.. :-) ? Regards Finn www.morphologic.dk PS. I'll have some giveaways at EW09 as well, but it will be more of the conventional sort.. :-)Article: 138561
On Feb 27, 1:58=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > rickman wrote: > > When you refer to "high end" processors, you are talking about a > > literal handful of devices compared to the hundreds or thousands of > > types of CPUs that are used in embedded systems. =A0If you are talking > > I'm referring to chips like Intel atom, new PowerQuicc IIP/III > processors etc. They usually have few PCIe ports as a default and if > they are not enough a switch is needed. And I don't see why > low end would not adopt PCIe. Each saved pin helps to get into a > smaller and cheaper package (altough wirebond and PCIe frequencies > might be challenging). Yes, I know which chips you are referring to. On a few high end chips (very high end) you are supporting the idea of utilizing the few PCIe interfaces rather than using a small number of GPIO pins. That is a tradeoff with those chips. But you are asking everyone buying FPGAs to pay for the Silicon to implement the hard PCIe interface and make it part of the configuration logic. On top of that, I am still not convinced that this can be done without some data in Flash which someone else pointed out is required for initilization of the PCI interface. Is this not the same with PCIe? > > about adding a "switch" then you are adding an extra chip and you can > > just as easily add any sort of chip to facilitate booting the FPGA. > > The problem is that there are only few vendors for special bridge chips > to GPIO etc. But for PCIe switches there are many vendors even > some with identical pinouts. That helps multisourcing for manufacturing. > Also Industrial temperature requirements narrow down the choices. You are dwelling on PCIe and I am not. There are many ways to skin a cat and most do not require anything special in the FPGA. Look at what I wrote without assuming this is using PCIe. > > I'm not familar with PCIe, but I know in PCI apps you can't use the > > PCI interface to boot the FPGA. =A0Are you talking about an embedded ap= p > > You could use it, if there would be FPGA on the market with hardcore IP > for PCI and someone would have thought of using it for configuration at > FPGA vendor. But that would have required too many pins etc. to be a > good and widely used solution. And how does the FPGA get the various parameters which the PCI protocol requires the FPGA to report? > > where you can work "around" the PCIe spec and just talk to the FPGA > > without worrying about the spec'd protocol? =A0In that case you have on= e > > I'm thinking that if you have hardcore IP for PCIe then it can > immediatly answer to the bus even if the FPGA is not loaded. If the > PCI configuration space would then have extended configuration register > that could be used to bang the data in via configuration cycles. Or > other option would be one hardcoded PCI BAR for the configuration image. > Memory mapped configuration image also might create some pretty > interesting opportunities for dynamic reconfiguration. So is this an extension to just to the FPGA or also to the PCI protocol? > > of the few apps where your PCIe port is dedicated to the FPGA. =A0Yes, > > in that case this works. =A0But that is rare enough that the FPGA > > vendors aren't going to add that capability for those few apps. > > With hardcore it can be done in a standard way, altough the boot > code needs some changes. And SIVGX, V5LXT, V5FXT, V6, S6, ArriaIIGX > at least have PCIe hardcore already. They just haven't built the > configuration interface yet (or they might have, but are not > documenting it). There are usually undocumented features in FPGAs > that are just not enabled, and might be enabled for few customers > with custom IP for testing. So how much additional work is required? I can assure you that if there were any significant number of users asking for something like this, it would appear. > > I seem to recall that there was support for a JTAG or some other > > serial interface on PCI, but it has been so long that I don't recall. > > I think you are referring to SMBus. It is I2C style slow (10kHz-100kHz) > interface. I think it would be too slow for FPGA configuration. Is that part of the PCI spec? I just remember that when I looked at PC/104+ and PCI/104 that they explicitly left out some serial control bus that I thought was JTAG. I don't remember it being SMBus which is really an Intel thing and is newer (at least in PCs) than PCI. SMBus is only two wires and would likely not have been left out of the PC/ 104+ spec. But the 4/5 wires of JTAG are a different matter. Of course it may have been an issue of the difficulty of using it in a stacked bus like PC/104. RickArticle: 138562
On Feb 26, 6:16 pm, "murl...@gmail.com" <murl...@gmail.com> wrote: > Inside dma_ddr2_if.v,i noticed the bottom 5 lsb all zero of > ingress_start_addr/egress_start_addr[27:6] . > > Why? is it PCIE or DDR2 requirement? > > How should i provide DDR2 address? Read this: <http://www.xilinx.com/support/documentation/ application_notes/xapp859.pdf> It is explained in there. ALArticle: 138563
rickman <gnuarm@gmail.com> wrote in news:55de02a8-97df-4a69-8ec4-9546dcac244e@r34g2000vbp.googlegroups.com: > On Feb 27, 1:58 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: >> rickman wrote: >> > When you refer to "high end" processors, you are talking about a >> > literal handful of devices compared to the hundreds or thousands of >> > types of CPUs that are used in embedded systems. If you are >> > talking >> >> I'm referring to chips like Intel atom, new PowerQuicc IIP/III >> processors etc. They usually have few PCIe ports as a default and if >> they are not enough a switch is needed. And I don't see why >> low end would not adopt PCIe. Each saved pin helps to get into a >> smaller and cheaper package (altough wirebond and PCIe frequencies >> might be challenging). > > Yes, I know which chips you are referring to. On a few high end chips > (very high end) you are supporting the idea of utilizing the few PCIe > interfaces rather than using a small number of GPIO pins. I predict that within a couple of years, many of the smallest (new) processors big enough to be able to run Vxworks or Linux will have at least a couple of lanes of PCIe. If we were back in the 1980s designing with 8051s, these new processors would seem very powerful, but they will be regarded as low end by the time I'm using them. If you want to use GPIO to configure that FPGA, you'll need a PCIe to GPIO bridge, wasting both a PCIe channel and and a bridge / GPIO chip. (I'm only half joking here.) Earlier in the thread I used the Intel Atom as an example. That processor & US15W support chip are aimed at netbooks, hence the lack of I/O other than USB and PCIe (mostly). These sort of architectures started to appear in embedded systems a couple of years ago. Soon they will be pervasive, except in the battery powered market (assuming that PCIe doesn't grow some sort of dynamic power down capability). There will still be 8051s and PICs but that's not what this thread's about. > That is a > tradeoff with those chips. But you are asking everyone buying FPGAs > to pay for the Silicon to implement the hard PCIe interface We're already paying for that in the newer families, e.g. V6. > and make it part of the configuration logic. This would be tiny compared to the PCIe end point logic that they already have in there. (And is "you pay for the programmable routing; the logic is free" still valid?) > On top of that, I am still not > convinced that this can be done without some data in Flash which > someone else pointed out is required for initilization of the PCI > interface. Is this not the same with PCIe? A general purpose bridge will need some sort of configuration device. There is nothing saying this has to apply to a specific PCIe bridge, or that any variable part of the configuration has to be stored in Flash or EEPROM. We already select the type of configuration with "mode" pins on the FPGA. I'd be quite prepared to waste an additional 3 or 4 pins on a 1000 to 1500 pin device to select one of several different pre-canned PCI configurations. The tradeoffs would be different for smaller packages, but I'm not using those. >> > about adding a "switch" then you are adding an extra chip and you >> > can just as easily add any sort of chip to facilitate booting the >> > FPGA. >> >> The problem is that there are only few vendors for special bridge >> chips to GPIO etc. But for PCIe switches there are many vendors even >> some with identical pinouts. That helps multisourcing for >> manufacturing. Also Industrial temperature requirements narrow down >> the choices. > > You are dwelling on PCIe and I am not. There are many ways to skin a > cat and most do not require anything special in the FPGA. Look at > what I wrote without assuming this is using PCIe. I'm the OP, which makes me the one dwelling on PCIe :) Besides, it's in the thread title. I'm really just interested in future trends. I think another poster (Kim Enkovaara) understood what I was getting at. Regards, AllanArticle: 138564
On Feb 27, 12:18=A0pm, Allan Herriman <allanherri...@hotmail.com> wrote: > rickman <gnu...@gmail.com> wrote innews:55de02a8-97df-4a69-8ec4-9546dcac2= 44e@r34g2000vbp.googlegroups.com: > > > > > On Feb 27, 1:58=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > >> rickman wrote: > >> > When you refer to "high end" processors, you are talking about a > >> > literal handful of devices compared to the hundreds or thousands of > >> > types of CPUs that are used in embedded systems. =A0If you are > >> > talking > > >> I'm referring to chips like Intel atom, new PowerQuicc IIP/III > >> processors etc. They usually have few PCIe ports as a default and if > >> they are not enough a switch is needed. And I don't see why > >> low end would not adopt PCIe. Each saved pin helps to get into a > >> smaller and cheaper package (altough wirebond and PCIe frequencies > >> might be challenging). > > > Yes, I know which chips you are referring to. =A0On a few high end chip= s > > (very high end) you are supporting the idea of utilizing the few PCIe > > interfaces rather than using a small number of GPIO pins. > > I predict that within a couple of years, many of the smallest (new) > processors big enough to be able to run Vxworks or Linux will have at > least a couple of lanes of PCIe. =A0If we were back in the 1980s designin= g > with 8051s, these new processors would seem very powerful, but they will > be regarded as low end by the time I'm using them. That may be true to some extent, but let's face it, even in five years, these very high end embedded processors, which are really embedded PCs, will still be the minority of the applications for embedded processors and likely an even smaller percentage of the controller for embedded FPGAs. There is no need for that level of power in most apps, for example the retail routers that are powered by ARM7 or ARM9 CPUs or the various processors in all sorts of handheld devices that don't need to run WinCE or even WinXP. So the need is just not there and is likely to not be there for some time to come. > If you want to use GPIO to configure that FPGA, you'll need a PCIe to > GPIO bridge, wasting both a PCIe channel and and a bridge / GPIO chip. > (I'm only half joking here.) No, for the vast majority of apps, you are totally joking... or at least exaggerating. PCIe is hardly ever the only means of comms other than in embedded PC chips perhaps. > Earlier in the thread I used the Intel Atom as an example. =A0That > processor & US15W support chip are aimed at netbooks, hence the lack of > I/O other than USB and PCIe (mostly). Exactly! It is a two chip set aimed at an app where an FPGA has no place. > These sort of architectures started to appear in embedded systems a > couple of years ago. =A0Soon they will be pervasive, except in the batter= y > powered market (assuming that PCIe doesn't grow some sort of dynamic > power down capability). You mean they have appeared in embedded PCs. That is a very different animal from embedded systems where the CPU is designed in rather than a CPU board being designed in. > There will still be 8051s and PICs but that's not what this thread's > about. No, it is about configuring FPGAs. > > =A0That is a > > tradeoff with those chips. =A0But you are asking everyone buying FPGAs > > to pay for the Silicon to implement the hard PCIe interface > > We're already paying for that in the newer families, e.g. V6. > > > and make it part of the configuration logic. > > This would be tiny compared to the PCIe end point logic that they > already have in there. > > (And is "you pay for the programmable routing; the logic is free" still > valid?) If you are in marketing, it is true. The rest of us have to pay hard cash. Silicon costs cash even if it is vanishingly small, there are still all the support costs. It will be added when it sells chips... and not before! There are two ways PCIe configuration can sell chips. One is if there are applications where the FPGA can't be used without this feature. That is a very, very small set of apps. The other is if the competition is selling chips with a useful feature that you don't have. When this happens, they will all start selling it. Just like Lattice selling low cost chips with SERDES functions. Now X and A are coming out with that too. But until that happened, it didn't cost X or A anything to not be selling that. > > On top of that, I am still not > > convinced that this can be done without some data in Flash which > > someone else pointed out is required for initilization of the PCI > > interface. =A0Is this not the same with PCIe? > > A general purpose bridge will need some sort of configuration device. =A0 > There is nothing saying this has to apply to a specific PCIe bridge, or > that any variable part of the configuration has to be stored in Flash or > EEPROM. Even the FPGA has to have various parameters preset, no? > We already select the type of configuration with "mode" pins on the > FPGA. =A0I'd be quite prepared to waste an additional 3 or 4 pins on a > 1000 to 1500 pin device to select one of several different pre-canned > PCI configurations. =A0The tradeoffs would be different for smaller > packages, but I'm not using those. What about a 256 pin device? You are talking about having to give up 4 pins on the processor as being trouble, why are pins so free on an FPGA? Besides, why would it be 3 or 4? Just what information has to be set in order for the FPGA to respond on a PCIe port? > >> > about adding a "switch" then you are adding an extra chip and you > >> > can just as easily add any sort of chip to facilitate booting the > >> > FPGA. > > >> The problem is that there are only few vendors for special bridge > >> chips to GPIO etc. But for PCIe switches there are many vendors even > >> some with identical pinouts. That helps multisourcing for > >> manufacturing. Also Industrial temperature requirements narrow down > >> the choices. > > > You are dwelling on PCIe and I am not. =A0There are many ways to skin a > > cat and most do not require anything special in the FPGA. =A0Look at > > what I wrote without assuming this is using PCIe. > > I'm the OP, which makes me the one dwelling on PCIe :) =A0Besides, it's i= n > the thread title. You are missing my point. By "dwelling" I meant you are so focused on the PCIe that you missed my point. You don't *need* PCIe to configure an FPGA. It is more complex, higher cost and uses more I/Os on both the CPU and the FPGA in the vast majority of designs. ***THAT*** is the main point. The other options are just better in all respects for 99.9% of current and 95% of foreseeable apps. The Atoms of the world are far in the minority. > I'm really just interested in future trends. =A0I think another poster > (Kim Enkovaara) understood what I was getting at. I understand, I don't agree with the need or the future view. I think that there are a large number of better ways to configure FPGAs than serial slave mode. But there is just little demand for it. When they start using PCIe in the ARM Cortex-Y99 processors being used in my electric toaster, then I will agree that it is time to make FPGAs bootable. Until then, I just don't see it as appropriate "value added". I may be wrong. The high end may come whizzing by me one day and I could very well miss it. RickArticle: 138565
On Feb 27, 5:06=A0pm, "Finn S. Nielsen" <removethis_finnsta...@vip.cybercity.dk> wrote: > Antti skrev: > > > > > Hi > > > it has nothing todo with Basic Stamps, just the PCB looks like a > > stamp, hence the name > > >http://www.trioflex.com/files/Stamp60-UM.pdf > > > preliminary user manual is now online. The first stamp is based on > > Actel FPGA > > and well the user manual maybe some interesting reading - for me it > > was surprise > > how nice actel tools have become (compared to what they used to be). > > > it is also interesting that Actel ist the only company offering small > > customizeable > > Soft-Core fully integrated with their IDE. PicoBlaze is still not > > fully officially supported > > and probably never will be integrated to Xilinx IDE. > > > Antti > > PS if some is interested i should have some give away units of the > > stamp > > at Embedded World. meeting at 12-536 > > Does it include an envelope... ?? :-) > > Anway, IF one had the time, one could sit down a wrap the picoblaze as > an IP core, add some BRAM interface block, define bus cores, picoblaze > to PLB bus bridge and other stuff nedded. That would make it easier to > hook it up to whatever core you have made that needs it - or for a > standalone system (type Atmel AVR and PIC systems). Updating the BRAM > with application code could be done with some perl/tcl scripts. But > integration of a debugger/simulator for it would be a difficult but very > usefull thing. Xilinx should put one person on doing that job. Or > perhaps the author of it would be keen on doing it. Kenn are you > reading.. :-) ? > > Regards > > Finnwww.morphologic.dk > > PS. I'll have some giveaways at EW09 as well, but it will be more of the > conventional sort.. :-) well, ALL of the other vendors (except Xilinx) are offering small soft- cores for BUS controller Actel CoreABC -> APB Altera avalon sequencer -> Avalon Lattice Micro8 -> Wishbone so PicoBlaze is the only one that has no external bus to connect peripherals AnttiArticle: 138566
Hmm... they even say when the ARM11 enabled Spartans are supposed to come out ! Antti http://www.microfpga.com/ and NO, there will be no free giveaway of the Silicon Blue stamps ;)Article: 138567
On Feb 27, 9:26=A0pm, Antti <Antti.Luk...@googlemail.com> wrote: > Hmm... > > they even say when the ARM11 enabled Spartans are supposed to come > out ! > > Antti http://www.microfpga.com/ > and NO, there will be no free giveaway of the Silicon Blue stamps ;) UUUUUUUUUPS!!!!!!!!!!!! I forgot the link the the authors of that information !!! sorry... the information is not coming from me, it was posted on german forums here: http://www.mikrocontroller.net/topic/124215#new Antti PS sorry.. today was a real bad day, everything went wrong! the hot-press at t-shirt print shop did fall onto floor, that just one example of those thingsArticle: 138568
On Feb 24, 4:48=A0pm, Gabor <ga...@alacron.com> wrote: > A lot of empty columns in the timing specifications, but > already errata listed for two devices of the family. > > Worth a look: > > http://www.latticesemi.com/corporate/newscenter/newsletters/newsfebru... > > Regards, > Gabor it seems they even have working silicon :) well PCIe was already offered in ECP2 so Xilinx will be the 3rd company shipping low cost FPGA with serdes (I assume Arria's are also shipping at the moment) AnttiArticle: 138569
>I'm referring to chips like Intel atom, new PowerQuicc IIP/III >processors etc. They usually have few PCIe ports as a default and if >they are not enough a switch is needed. And I don't see why >low end would not adopt PCIe. Each saved pin helps to get into a >smaller and cheaper package (altough wirebond and PCIe frequencies >might be challenging). Does anybody make a PCIe to GPIO chip? My guess is that sort of junk would go via USB rather than PCIe. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138570
>The PowerPC405/440 core in the Virtex devices has it's own instruction to >do little endian/big endian conversion. Also you can mark memory pages as >little endian/big endian. If I mark all the pages wrong endian, does that change the system into a clean other-endian system? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138571
On Feb 26, 6:14=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Feb 26, 10:56=A0am, mansoor.nas...@gmail.com wrote: > > > > > > > On Feb 25, 11:15=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > On Feb 23, 4:49=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > On Feb 23, 12:42=A0pm, Dave Pollum <vze24...@verizon.net> wrote: > > > > > > On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > Hi, > > > > > > It is intersting to find that $24.50 is for an Altera ByteBlast > > > > > > programmer mentioned in a topics in FPGA group. > > > > > > > I need to buy a programmer suitable for Xilinx Virtex II XC2V15= 00 chip > > > > > > only. > > > > > > > Please give any tips where I can buy a cheap programmer. > > > > > > > Thank you. > > > > > > > Weng > > > > > > Digilent (digilentinc.com) has inexpensive programming cables. > > > > > -Dave Pollum > > > > > Hi Dave, > > > > Good information! I need cables too. But hopefully I may get a set = of > > > > programmer plus its cables from one person or a company. > > > > > Weng- Hide quoted text - > > > > > - Show quoted text - > > > > Hi Dave, > > > I checked Digilent.com website and I am not sure which one works for > > > my system: Xilinx Virtext II XC2V 1000. > > > > JTAG Programming Cable $12.00 > > > low-cost JTAG configuration solution > > > for use with any JTAG-programmable device > > > connects directly to the parallel port of a PC, and to a standard 6- > > > pin JTAG programming header > > > can program devices that have a JTAG voltage of 1.8V or greater > > > > I found my board has a 14-pin connector, but above specs says it has = a > > > 6-pin JTAG programming header. Is it fit? > > > > Is Xilinx iMPACT software still usable? > > > > Please give me a help to determine if which is fit. > > > > Thank you. > > > > Weng > > > software still usable, go for jtag usb programming cable (37.95$), it > > will be faster > > it works with impact software > > for jtag the most important six connections are VCC, GND, TMS, TDI, > > TDO, TCK > > the 14 pin connector repeats some of the pins but effectively these > > six pins are required to program xilinx fpgas. > > You can make a manual adaptor with 6 Pin MTE Cable (also on the same > > page) which will break individual signal (TMS, TCK etc) into wires > > > hope this helps > > > mak- Hide quoted text - > > > - Show quoted text - > > Hi Mak, > Your comments are very instructive and helpful. > > Another question: > Can JTAG USB programming capable be used together with Xilinx > ChipScope? > > I think if IMPACT works with the cable, ChipScope should work too, is > it true? > > Thank you. > > Weng- Hide quoted text - > > - Show quoted text - Hi, Finally Digilent JTAG Programming Cable is not compatible with Xilinx iMPACT and ChipScope software based on the following information: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/8053c44b= 22360639/ecc92dcddcf0a84e?lnk=3Dgst&q=3Dchipscope+cable#ecc92dcddcf0a84e "Note that Digilent's JTAG/USB cable does not work with the Xilinx Impact program. You'll have to use Digilent's programming software or find other software that supports that cable. That also means that the Digilent cable doesn't support Xilinx Chipscope, or the EDK debugger. " Thank Dave for the information. WengArticle: 138572
hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote in news:nLSdndGNAs4R7zXUnZ2dnUVZ_oWWnZ2d@megapath.net: > >>I'm referring to chips like Intel atom, new PowerQuicc IIP/III >>processors etc. They usually have few PCIe ports as a default and if >>they are not enough a switch is needed. And I don't see why >>low end would not adopt PCIe. Each saved pin helps to get into a >>smaller and cheaper package (altough wirebond and PCIe frequencies >>might be challenging). > > Does anybody make a PCIe to GPIO chip? The bridges aimed at embedded systems typically have a few GPIO lines, usually 8 or fewer. Of course they're just extras, and not the main function of the bridge chip. > My guess is that sort of junk would go via USB rather than PCIe. Parts from FTDI come to mind. They are not too expensive (< $10 from Digikey) and there is a wealth of software support available. I don't know of any others though. Regards, AllanArticle: 138573
rickman <gnuarm@gmail.com> wrote in news:62bd320f-8525-4302-8dd8-d9cf13545e3c@s20g2000yqh.googlegroups.com: > On Feb 27, 12:18 pm, Allan Herriman <allanherri...@hotmail.com> wrote: >> rickman <gnu...@gmail.com> wrote >> innews:55de02a8-97df-4a69-8ec4-9546dcac2 > 44e@r34g2000vbp.googlegroups.com: >> >> >> >> > On Feb 27, 1:58 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: >> >> rickman wrote: >> >> > When you refer to "high end" processors, you are talking about a >> >> > literal handful of devices compared to the hundreds or thousands >> >> > of types of CPUs that are used in embedded systems. If you are >> >> > talking >> >> >> I'm referring to chips like Intel atom, new PowerQuicc IIP/III >> >> processors etc. They usually have few PCIe ports as a default and >> >> if they are not enough a switch is needed. And I don't see why >> >> low end would not adopt PCIe. Each saved pin helps to get into a >> >> smaller and cheaper package (altough wirebond and PCIe frequencies >> >> might be challenging). >> >> > Yes, I know which chips you are referring to. On a few high end >> > chip > s >> > (very high end) you are supporting the idea of utilizing the few >> > PCIe interfaces rather than using a small number of GPIO pins. >> >> I predict that within a couple of years, many of the smallest (new) >> processors big enough to be able to run Vxworks or Linux will have at >> least a couple of lanes of PCIe. If we were back in the 1980s >> designin > g >> with 8051s, these new processors would seem very powerful, but they >> will be regarded as low end by the time I'm using them. > > That may be true to some extent, but let's face it, even in five > years, these very high end embedded processors, which are really > embedded PCs, will still be the minority of the applications for > embedded processors and likely an even smaller percentage of the > controller for embedded FPGAs. There is no need for that level of > power in most apps, for example the retail routers that are powered by > ARM7 or ARM9 CPUs or the various processors in all sorts of handheld > devices that don't need to run WinCE or even WinXP. So the need is > just not there and is likely to not be there for some time to come. > > >> If you want to use GPIO to configure that FPGA, you'll need a PCIe to >> GPIO bridge, wasting both a PCIe channel and and a bridge / GPIO >> chip. (I'm only half joking here.) > > No, for the vast majority of apps, you are totally joking... or at > least exaggerating. PCIe is hardly ever the only means of comms other > than in embedded PC chips perhaps. > > >> Earlier in the thread I used the Intel Atom as an example. That >> processor & US15W support chip are aimed at netbooks, hence the lack >> of I/O other than USB and PCIe (mostly). > > Exactly! It is a two chip set aimed at an app where an FPGA has no > place. > > >> These sort of architectures started to appear in embedded systems a >> couple of years ago. Soon they will be pervasive, except in the >> batter > y >> powered market (assuming that PCIe doesn't grow some sort of dynamic >> power down capability). > > You mean they have appeared in embedded PCs. That is a very different > animal from embedded systems where the CPU is designed in rather than > a CPU board being designed in. > > >> There will still be 8051s and PICs but that's not what this thread's >> about. > > No, it is about configuring FPGAs. > > >> > That is a >> > tradeoff with those chips. But you are asking everyone buying >> > FPGAs to pay for the Silicon to implement the hard PCIe interface >> >> We're already paying for that in the newer families, e.g. V6. >> >> > and make it part of the configuration logic. >> >> This would be tiny compared to the PCIe end point logic that they >> already have in there. >> >> (And is "you pay for the programmable routing; the logic is free" >> still valid?) > > If you are in marketing, it is true. The rest of us have to pay hard > cash. Silicon costs cash even if it is vanishingly small, there are > still all the support costs. It will be added when it sells chips... > and not before! There are two ways PCIe configuration can sell > chips. One is if there are applications where the FPGA can't be used > without this feature. That is a very, very small set of apps. The > other is if the competition is selling chips with a useful feature > that you don't have. When this happens, they will all start selling > it. Just like Lattice selling low cost chips with SERDES functions. > Now X and A are coming out with that too. But until that happened, it > didn't cost X or A anything to not be selling that. > > >> > On top of that, I am still not >> > convinced that this can be done without some data in Flash which >> > someone else pointed out is required for initilization of the PCI >> > interface. Is this not the same with PCIe? >> >> A general purpose bridge will need some sort of configuration device. >> There is nothing saying this has to apply to a specific PCIe >> bridge, or that any variable part of the configuration has to be >> stored in Flash or EEPROM. > > Even the FPGA has to have various parameters preset, no? > > >> We already select the type of configuration with "mode" pins on the >> FPGA. I'd be quite prepared to waste an additional 3 or 4 pins on a >> 1000 to 1500 pin device to select one of several different pre-canned >> PCI configurations. The tradeoffs would be different for smaller >> packages, but I'm not using those. > > What about a 256 pin device? You are talking about having to give up > 4 pins on the processor as being trouble, why are pins so free on an > FPGA? Besides, why would it be 3 or 4? Just what information has to > be set in order for the FPGA to respond on a PCIe port? > > >> >> > about adding a "switch" then you are adding an extra chip and >> >> > you can just as easily add any sort of chip to facilitate >> >> > booting the FPGA. >> >> >> The problem is that there are only few vendors for special bridge >> >> chips to GPIO etc. But for PCIe switches there are many vendors >> >> even some with identical pinouts. That helps multisourcing for >> >> manufacturing. Also Industrial temperature requirements narrow >> >> down the choices. >> >> > You are dwelling on PCIe and I am not. There are many ways to skin >> > a cat and most do not require anything special in the FPGA. Look >> > at what I wrote without assuming this is using PCIe. >> >> I'm the OP, which makes me the one dwelling on PCIe :) Besides, it's >> i > n >> the thread title. > > You are missing my point. By "dwelling" I meant you are so focused on > the PCIe that you missed my point. You don't *need* PCIe to configure > an FPGA. It is more complex, higher cost and uses more I/Os on both > the CPU and the FPGA in the vast majority of designs. ***THAT*** is > the main point. The other options are just better in all respects for > 99.9% of current and 95% of foreseeable apps. The Atoms of the world > are far in the minority. Rick, I think you're the one missing the point. I think those (obviously fabricated) stats relate to your personal experience and don't neccessarily apply to all applications. *My* personal experience is that 100% of systems that *I design* would be made smaller and cheaper if FPGAs could configure over PCIe. I'm well aware that I'm probably in the minority of designers here. But that isn't to say that the issues I face in design are not important. You employ logical fallacies in your arguments. E.g. I used an example of a 1000 to 1500 pin FPGA. You reply to my statement by implying that it doesn't work for a 256 pin FPGA. Well, I already knew that, which is why I qualified my statement with the size of the FPGA in the first place. I just don't know how to respond to bad arguments like that except in an emotive way, and as a result I'm stopping posting (since caf is a civilised place). AllanArticle: 138574
Does anyone have an idea or where i can find information on how can to implement a cordic algorithm on an altera cyclone II or cyclone III fpga? -- xristos ------------------------------------------------------------------------ xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15 View this thread: http://www.fpgacentral.com/group/showthread.php?t=88112
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