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
On 16 Nov., 14:57, "matrix" <ravikrishnanunni@n_o_s_p_a_m.gmail.com> wrote: > C:\Actel\Libero_v9.1\Synopsys\synplify_E201009A-1\lib\xilinx\unisim.vhd" > I am not using any Unisim components in the Actel Libero project. Then what > cause can result in this error. Are you sure that you have no usage of library unisim in any file? Try searching for "library unisim" in all hdl files. I guess that Synplify has some build in mechanismes to check under <libpath>/xilinx if unisim or simprim is used in design. But actually I'm surprised that even the Actelversion of Synplify has this build in. bye ThomasArticle: 153026
On Wed, 16 Nov 2011 07:57:19 -0600, matrix wrote: > Hello all. > I obtained the following error message. "Can't open input file > C:\Actel\Libero_v9.1\Synopsys\synplify_E201009A-1\lib\xilinx\unisim.vhd" > I am not using any Unisim components in the Actel Libero project. Then > what cause can result in this error. You may have replaced any such components, but it is possible that some source files still contain (now unnecessary) library clauses, referencing the unisim library. - BrianArticle: 153027
I started out by modifying the base PCIe implementation to accept multiple DWORD packets, however it turned out that the PCIe root port in my PC did not support this. You need to implement DMA to get more performance. Typing "xilinx pcie dma" into google gave me the following result (you really should try google next time...) : Bus Master Performance Demonstration Reference Design for the Xilinx Endpoint PCI Express Solutions http://www.xilinx.com/support/documentation/application_notes/xapp1052.pdf I use this design a great deal, it comes with the required registers already implemented but not blockram. Kind regards, Sam Collinson On Nov 16, 6:42=A0am, self <padu...@gmail.com> wrote: > Hello, > > I have used the Xilinx LogiCore Integrated Block for PCI Expres > several times in the past. On those occasions I have hacked into the > autogenerated example design to bring a standard parallel interface up > to the top level for access to registers and block ram. =A0This work has > always been for prototyping and was not really production firmware. > Working this way the PCI Express performance is really low because the > Logicore IP does not support burst transfers or DMA. =A0The software > engineer hacks the linux driver to prevent any PCI Express accesses of > greater than one word so we don't get bus errors. > > I just genenerated a version 2.4 AXI4 compatible PCIe core for V6 > using ISE 13.3 and I see the design still supports only single word > accesses. > > Now we are dong a production design using PCIe and I would like to get > the full performance of the interface. =A0In particular I must support > burst transfers. =A0Ideally I will also provide DMA logic. > > Can anyone advise me where to start in order to get where I want to > go? > > Am I starting too low using the Xilinx Logicore design? > > Does Xilinx provide a better core or reference design with burst > transfer and DMA? > > Any advice is greatly appreciated. > > =A0 PedroArticle: 153028
On Nov 14, 5:04=A0pm, maverick <sheikh.m.far...@gmail.com> wrote: > Hi, > I am looking for a decent PCIe (Gen1 & Gen2) based FPGA board with > preferably 2 Xilinx Virtex 5 FPGAs on it. A 2GB DDR2 SODIMM and > minimum 256 MB RAM is preferred. Other onboard periphals may include > gigbit ethernet and a USB 2.0. FPGAs must be Virtex-5 LX330T or higher > capacity. Other than that nothing much is actually required. I have > been searching for such a board but most of them are packed with other > peripherals making them too costly. I basically need 2 (or more) V5 > LX330T FPGAs on a board with PCIe (x8) with 2GB DDR2 and 256 or higher > RAM. Any suggestions please........ To add further, I was initially using Avnet Virtex 5 Development board with V5 LXT110-4 FPGA (AES-XLX-V5LXT-PCIE110-G). Now I need a board with a bigger FPGA. The same board with V5 LXT330 could have solved my problem but unfortunately that particular FPGA board is discontinued and no more available from Avnet. Since my initial development took place on the LXT110 board, I would like to have a replacement which is closer to the original Avnet board so that the migration time is reduced as much as possible. Please suggest.......Article: 153029
>On Wed, 16 Nov 2011 07:57:19 -0600, matrix wrote: > >> Hello all. >> I obtained the following error message. "Can't open input file >> C:\Actel\Libero_v9.1\Synopsys\synplify_E201009A-1\lib\xilinx\unisim.vhd" >> I am not using any Unisim components in the Actel Libero project. Then >> what cause can result in this error. > >You may have replaced any such components, but it is possible that some >source files still contain (now unnecessary) library clauses, referencing >the unisim library. > >- Brian > Solved. One of the source files contained a library initialization for unisim, as Thomas and Brian had pointed out. Removed that clause and the error message disappeared. Thank you all. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153030
Dear friends, I am doing a project for nexys-2 spartan 3 board. To reduce time a first design a module in "iverilog.exe" and run using "vvp.exe". This is a very simple and fast approach. However sometimes there are real problems while trying to port the code to xilinx ISE. I did some research to see if Xilinx tools could be used for behavioural modeling. It seems that it can be done: http://www.fpgarelated.com/usenet/fpga/show/96771-1.php However I am not sure weather or not I am using the "vlogcomp.exe" and "fuse.exe" commands correctly. My code gets compiled without error but when I try to run the executable obtained from fuse command. "the ....exe has stopped working". I have windows 7. Hope I have put my thoughts to words correctly. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153031
Someone on Linkedin asked about a stand alone device for programming the flash for FPGAs in the field or in a production environment. There doesn't seem to be anything currently available like this. Looking at the big three manufacturers I see at least two formats for the files that might be used. Xilinx and Lattice use SVF with Xilins offering support for a compressed version called... XSVF of course. Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears to be a defacto industry standard developed by a company. I'm curious why two standards came about. Was there a problem with using the version the company developed? I'm assuming the industry version came first and the JEDEC version came later. Or is that wrong? It won't be too much trouble to support both, but I don't get why both standards exist. How do you program production devices? I know in large facilities they pay big bucks for JTAG hardware and software that will work across the spectrum including test and diagnosis. I'm thinking there is a market for a more limited device that is just used to program the non-volatile memory in embedded systems in an efficient manner for production and field upgrades. Any thoughts? RickArticle: 153032
2011-11-18 23:14, rickman skrev:
> Someone on Linkedin asked about a stand alone device for programming
> the flash for FPGAs in the field or in a production environment.
> There doesn't seem to be anything currently available like this.
> Looking at the big three manufacturers I see at least two formats for
> the files that might be used. Xilinx and Lattice use SVF with Xilins
> offering support for a compressed version called... XSVF of course.
> Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
> to be a defacto industry standard developed by a company.
>
> I'm curious why two standards came about. Was there a problem with
> using the version the company developed? I'm assuming the industry
> version came first and the JEDEC version came later. Or is that
> wrong? It won't be too much trouble to support both, but I don't get
> why both standards exist.
>
> How do you program production devices? I know in large facilities
> they pay big bucks for JTAG hardware and software that will work
> across the spectrum including test and diagnosis. I'm thinking there
> is a market for a more limited device that is just used to program the
> non-volatile memory in embedded systems in an efficient manner for
> production and field upgrades. Any thoughts?
>
> Rick
Programming procedure for programming a bare at91sam9 board.
1. Insert SD-Card
2. Press reset
3. Wait until LED blinks
4. Remove SD-Card
5. Press Reset
Application boots...
Procedure for updating the linux kernel in a preprogrammed board.
1. Connect board to host PC using USB.
2. Reset the board in the USB Mass Storage mode.
3. Wait until FAT partition window appears on the host PC.
4. Clíck on the new kernel version, drag and drop it on the FAT window
5. Reset the PC into normal linux boot sequence.
--
Best Regards
Ulf Samuelsson
Article: 153033On 18 Nov., 23:14, rickman <gnu...@gmail.com> wrote: > Someone on Linkedin asked about a stand alone device for programming > the flash for FPGAs in the field or in a production environment. > There doesn't seem to be anything currently available like this. > Looking at the big three manufacturers I see at least two formats for > the files that might be used. =A0Xilinx and Lattice use SVF with Xilins > offering support for a compressed version called... XSVF of course. > Altera uses JAM. =A0JAM seems to be a JEDEC standard while SVF appears > to be a defacto industry standard developed by a company. > > I'm curious why two standards came about. =A0Was there a problem with > using the version the company developed? =A0I'm assuming the industry > version came first and the JEDEC version came later. =A0Or is that > wrong? =A0It won't be too much trouble to support both, but I don't get > why both standards exist. > > How do you program production devices? =A0I know in large facilities > they pay big bucks for JTAG hardware and software that will work > across the spectrum including test and diagnosis. =A0I'm thinking there > is a market for a more limited device that is just used to program the > non-volatile memory in embedded systems in an efficient manner for > production and field upgrades. =A0Any thoughts? > > Rick I know where I've been we always ended up building our own board with MCU on it for the production testing. Usually involving bit- banging(everything from JTAG to PCI) a bootloader or test program into the dut and programming a flash via uart/spi or something like that the code to be programmed was usually store on flash on the board, so unless you needed to add serial numbers and such it could be used standalone, just plug it into the dut and push the program button and done We did at one point try some jtag hw, but it could never really do what we wanted -LasseArticle: 153034
On Nov 18, 4:14=A0pm, rickman <gnu...@gmail.com> wrote: > Someone on Linkedin asked about a stand alone device for programming > the flash for FPGAs in the field or in a production environment. > There doesn't seem to be anything currently available like this. > Looking at the big three manufacturers I see at least two formats for > the files that might be used. =A0Xilinx and Lattice use SVF with Xilins > offering support for a compressed version called... XSVF of course. > Altera uses JAM. =A0JAM seems to be a JEDEC standard while SVF appears > to be a defacto industry standard developed by a company. > > I'm curious why two standards came about. =A0Was there a problem with > using the version the company developed? =A0I'm assuming the industry > version came first and the JEDEC version came later. =A0Or is that > wrong? =A0It won't be too much trouble to support both, but I don't get > why both standards exist. > > How do you program production devices? =A0I know in large facilities > they pay big bucks for JTAG hardware and software that will work > across the spectrum including test and diagnosis. =A0I'm thinking there > is a market for a more limited device that is just used to program the > non-volatile memory in embedded systems in an efficient manner for > production and field upgrades. =A0Any thoughts? > > Rick IEEE 1532 is something that is a bit newer, I believe both xilinx and altera support it, not sure 'bout the others. http://grouper.ieee.org/groups/1532/ (we are primarily Xilinx users...) As for programming, it depends on the system. These days we usually have a PC in the test fixture for all but the simplest of boards, so we use a Xilinx cable for the initial load. We usually have the Xilinx part as a coprocessor with other devices, so even if the xilinx boots first, we have other devices that can do updates to the memory already on-board. Even if you don't have a CPU, it's not hard to put in a picoblaze core and do a loader to update a SPI flash via bit-banging. You could probably do one with access to raw SD/MMC cards without too much trouble.Article: 153035
On 18/11/11 23:14, rickman wrote: > Someone on Linkedin asked about a stand alone device for programming > the flash for FPGAs in the field or in a production environment. > There doesn't seem to be anything currently available like this. > Looking at the big three manufacturers I see at least two formats for > the files that might be used. Xilinx and Lattice use SVF with Xilins > offering support for a compressed version called... XSVF of course. > Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears > to be a defacto industry standard developed by a company. > > I'm curious why two standards came about. Was there a problem with > using the version the company developed? I'm assuming the industry > version came first and the JEDEC version came later. Or is that > wrong? It won't be too much trouble to support both, but I don't get > why both standards exist. > > How do you program production devices? I know in large facilities > they pay big bucks for JTAG hardware and software that will work > across the spectrum including test and diagnosis. I'm thinking there > is a market for a more limited device that is just used to program the > non-volatile memory in embedded systems in an efficient manner for > production and field upgrades. Any thoughts? > > Rick It depends on the devices in question. Many larger microcontrollers have a bootloader in ROM that you can use to program them over a serial link or perhaps USB. Smaller microcontrollers can often be programmed easily using a JTAG or other debugging port, or an SPI-like interface (such as AVR devices). Typically that means using the manufacturer's own JTAG debuggers and software, but these are always far cheaper than the JTAG test equipment and software you describe. I have also used the JTAG or BDM port of bigger microcontrollers, combined with a cheap hardware interface and gdb, to script programming and testing setups. For ARM devices you can use OpenOCD or Urjtag in a similar fashion. For devices that can boot from a serial flash, the easiest method is often to make these pins available on a header, along with the "boot mode" control pins for the device. Then you can make a little card with a serial flash device that you plug into the board for initial bootup - this software can then test the board and program the real code into the main memory. If you have a serial flash on the board as the main memory, then you can have a similar header that lets an off-board device hold the processor or FPGA in reset while it programs the serial flash. You can make such a device using an FTDI 2232H module and a few wires.Article: 153036
rickman <gnuarm@gmail.com> wrote: >Someone on Linkedin asked about a stand alone device for programming >the flash for FPGAs in the field or in a production environment. >There doesn't seem to be anything currently available like this. >Looking at the big three manufacturers I see at least two formats for >the files that might be used. Xilinx and Lattice use SVF with Xilins >offering support for a compressed version called... XSVF of course. >Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears >to be a defacto industry standard developed by a company. > >How do you program production devices? I know in large facilities >they pay big bucks for JTAG hardware and software that will work >across the spectrum including test and diagnosis. I'm thinking there >is a market for a more limited device that is just used to program the >non-volatile memory in embedded systems in an efficient manner for >production and field upgrades. Any thoughts? I try to stick with devices which can be programmed over a standard serial port. A programmer is nothing more than a USB to serial converter. Very convenient. If I need in system programming I use a standard programmer with a cable. IC socket to put in the programmer at one end, a special connector on the other end. In order to program large numbers of devices I once build a special rig with 8 Jtag and 8 serial ports. The devices to be programmed where designed to be plugged into this programmer. There is a lot you can do at the design stage to make programming easier & faster. A cheap device may cost more in the end if the programming takes more time & effort. Time is expensive in many places. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153037
In comp.arch.embedded rickman <gnuarm@gmail.com> wrote: > How do you program production devices? One option that hasn't been mentioned yet is to buy your devices pre-programmed from the distributor. There are of course plenty of perfectly valid reasons why this may not be an option for you, but if they do not concern you, there's also a lot to be said for transforming this into Someone Else's Problem. -aArticle: 153038
rickman wrote: > Someone on Linkedin asked about a stand alone device for programming > the flash for FPGAs in the field or in a production environment. You can access the flash for FPGAs from the FPGA itself when configured, at least for the Altera Cyclone parts. So initially you need something like JTAG for programming it, but updates can be done from the FPGA itself. I've implemented update procedures from NIOS and for other projects with pure VHDL, with a I2C slave for receiving the update data and reading back the flash for verifying. You can use the rbf file for programming the flash (bitorder is important), which can be sent from a microcontroller when its flash was updated with a new firmware. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 153039
If you want DMA you either need to write your own DMA controller or buy a ready made core. Xilinx only provide the PCIe core. I have done this before so if you want to contact me I may be able to help you. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153040
On Nov 18, 9:10=A0pm, "AMD...@gmail.com" <amd...@gmail.com> wrote: > On Nov 18, 4:14=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > > > > > > > Someone on Linkedin asked about a stand alone device for programming > > the flash for FPGAs in the field or in a production environment. > > There doesn't seem to be anything currently available like this. > > Looking at the big three manufacturers I see at least two formats for > > the files that might be used. =A0Xilinx and Lattice use SVF with Xilins > > offering support for a compressed version called... XSVF of course. > > Altera uses JAM. =A0JAM seems to be a JEDEC standard while SVF appears > > to be a defacto industry standard developed by a company. > > > I'm curious why two standards came about. =A0Was there a problem with > > using the version the company developed? =A0I'm assuming the industry > > version came first and the JEDEC version came later. =A0Or is that > > wrong? =A0It won't be too much trouble to support both, but I don't get > > why both standards exist. > > > How do you program production devices? =A0I know in large facilities > > they pay big bucks for JTAG hardware and software that will work > > across the spectrum including test and diagnosis. =A0I'm thinking there > > is a market for a more limited device that is just used to program the > > non-volatile memory in embedded systems in an efficient manner for > > production and field upgrades. =A0Any thoughts? > > > Rick > > IEEE 1532 is something that is a bit newer, I believe both xilinx and > altera > support it, not sure 'bout the others.http://grouper.ieee.org/groups/1532= / > > (we are primarily Xilinx users...) > > As for programming, it depends on the system. =A0These days we usually > have a PC in the test fixture for all but the simplest of boards, so > we use > a Xilinx cable for the initial load. =A0We usually have the Xilinx part > as a coprocessor > with other devices, so even if the xilinx boots first, we have other > devices that > can do updates to the memory already on-board. > > Even if you don't have a CPU, it's not hard to put in a picoblaze core > and do a > loader to update a SPI flash via bit-banging. =A0You could probably do > one with > access to raw SD/MMC cards without too much trouble. I tried to download the 1532 standard draft, but I need a user id and password. I've found other draft standards from the IEEE that are available. Any idea where this one can be found? RickArticle: 153041
Hi, someone mentioned the FT2232 based JTAG adapters. I guess they're common usage (by now) are the reason why noone really has to pay big bucks anymore for factory programming. We had originally designed our own FTDI based JTAG (called ICEbear) for Blackfin and modified various open source tools to work with it. Some examples to program Xilinx devices: - xc3sprog - xilprg They're linuxish and command line tools, but do the job, they can be interfaced with expensive ICT hardware easily. Moreover, the ICTs are somewhat fading out on newer hardware, because we do all the system tests over the same JTAG port using test scripts. I guess the problem with the device programming issues is, that chip vendors have confusing retentive policies when it comes to JTAG and cling on selling their expensive and mostly unflexible tools. This can be partially understood, because JTAG is such a darn powerful tool for reverse engineering chip architectures. However, this wall will break sooner or later as well... Greetings, - MartinArticle: 153042
Jon, The application note I posted is a DMA controller provided for free by Xilinx. Kind regards, Sam Collinson On Nov 20, 9:08=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > If you want DMA you either need to write your own DMA controller or buy a > ready made core. Xilinx only provide the PCIe core. I have done this befo= re > so if you want to contact me I may be able to help you. > > Jon > > --------------------------------------- > Posted throughhttp://www.FPGARelated.comArticle: 153043
On Sun, 20 Nov 2011 15:41:14 -0800, Sam Collinson wrote: > Jon, > The application note I posted is a DMA controller provided for free by > Xilinx. > Kind regards, > Sam Collinson Verilog only, unfortunately. - BrianArticle: 153044
Op Fri, 18 Nov 2011 23:14:55 +0100 schreef rickman <gnuarm@gmail.com>: > [...] > > I'm curious why two standards came about. Was there a problem with > using the version the company developed? I'm assuming the industry > version came first and the JEDEC version came later. Or is that > wrong? It won't be too much trouble to support both, but I don't get > why both standards exist. http://xkcd.com/927/ -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (Remove the obvious prefix to reply.)Article: 153045
On Nov 21, 9:10=A0am, "Boudewijn Dijkstra" <sp4mtr4p.boudew...@indes.com> wrote: > Op Fri, 18 Nov 2011 23:14:55 +0100 schreef rickman <gnu...@gmail.com>: > > > [...] > > > I'm curious why two standards came about. =A0Was there a problem with > > using the version the company developed? =A0I'm assuming the industry > > version came first and the JEDEC version came later. =A0Or is that > > wrong? =A0It won't be too much trouble to support both, but I don't get > > why both standards exist. > > http://xkcd.com/927/ > > -- > Gemaakt met Opera's revolutionaire e-mailprogramma: =A0http://www.opera.c= om/mail/ > (Remove the obvious prefix to reply.) lolArticle: 153046
Hello, I like to design a prototype network application on a Spartan 3E board, and would need to have an RTOS with support for TCP/IP sockets. Which soft core processor and RTOS would be recommendable to use on Spartan 3E board, to have access to TCP/IP sockets that direct to the Ethernet port on the Spartan 3E board? Does the soft core processor come with a compiler for writing software in C? I like to have C compiler where I can use sockets, etc. Once the prototype is ready on the Spartan 3E board, is it easy to convert it to a PCB board (containing the FPGA and Ethernet circuitry)? Thanks, Pascal --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153047
On 22 nov, 10:52, "pascal_sweden" <pascal_sweden@n_o_s_p_a_m.hotmail.com> wrote: > Hello, > > I like to design a prototype network application on a Spartan 3E board, > and would need to have an RTOS with support for TCP/IP sockets. > > Which soft core processor and RTOS would be recommendable to use on Spartan > 3E board, to have access to TCP/IP sockets that direct to the Ethernet port > on the Spartan 3E board? > > Does the soft core processor come with a compiler for writing software in > C? > I like to have C compiler where I can use sockets, etc. > > Once the prototype is ready on the Spartan 3E board, is it easy to convert > it to a PCB board (containing the FPGA and Ethernet circuitry)? > > Thanks, > > Pascal > > --------------------------------------- > Posted throughhttp://www.FPGARelated.com Well have you looked at SDK and the Microblaze processor from Xilinx? The compiler is GCC and AFAIK, there is a lot of support from RTOS vendors. You can even use FreeRTOS http://www.freertos.org/.Article: 153048
On Tue, 22 Nov 2011 09:52:42 -0600, pascal_sweden wrote: > Hello, > > I like to design a prototype network application on a Spartan 3E board, > and would need to have an RTOS with support for TCP/IP sockets. > > Which soft core processor and RTOS would be recommendable to use on > Spartan 3E board, to have access to TCP/IP sockets that direct to the > Ethernet port on the Spartan 3E board? Few RTOS's by themselves have TCP/IP support -- you either need to use a honkin' big RTOS (like RT Linux, or VxWorks), or you need to buy a little RTOS and someone's TCP/IP software ala cart. What you want depends on what you're doing, but you may want to take a look at Micrium's offerings. > Does the soft core processor come with a compiler for writing software > in C? Most do. > I like to have C compiler where I can use sockets, etc. Any C compiler will let you use sockets -- because TCP/IP sockets have nothing to do with the compiler. They have everything to do with what the OS (or the separate TCP/IP stack) provides, though. > Once the prototype is ready on the Spartan 3E board, is it easy to > convert it to a PCB board (containing the FPGA and Ethernet circuitry)? If your level of knowledge of electronics is as low as your level of knowledge of software, it'll be an uphill battle. But you'll certainly come out the other side smarter than when you went in. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153049
>Hello, > >I like to design a prototype network application on a Spartan 3E board, >and would need to have an RTOS with support for TCP/IP sockets. > >Which soft core processor and RTOS would be recommendable to use on Spartan >3E board, to have access to TCP/IP sockets that direct to the Ethernet port >on the Spartan 3E board? > >Does the soft core processor come with a compiler for writing software in >C? >I like to have C compiler where I can use sockets, etc. > >Once the prototype is ready on the Spartan 3E board, is it easy to convert >it to a PCB board (containing the FPGA and Ethernet circuitry)? > >Thanks, It is possible to run LwIP on a MicroBlaze in a Spartan 3. --------------------------------------- Posted through http://www.FPGARelated.com
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