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
Den 05-10-2011 16:09, Finn S. Nielsen skrev: > Hello all, > > Does anyone know why I keep getting errors like this: > > " > ERROR:EDK:708 - Can not get list of netlist files for core > xps_fb_img_xform 1.01.a . > The pcore has a pre-synthesized netlist specified through BBD and the > list of parameter combinations listed for the instance in MHS does not > match any of the combinations in the BBD. > " > > I've enclosed a file showing how the core entry looks like in the MHS > file, as well as the cores BBD file contents. > > Could it be something with directory paths and/or spaces or whatever. > There are no tab characters in the BBD file. > > It's quite annoying. > > Thanks all, > > Finn S. Nielsen > Morphologic ApS > www.morphologic.dk OK All, here's an explanation: XPS will read the default parameter values and try and match these settings with the combinations in the BBD file. If it doesn't find it it issues an error message. This does however have nothing to do with the parameters in the MHS file which it will only check during system build... So the default parameter combination must exist to avoid the error message - which should not really be an error, but rather a warning instead.. ( add that to the gazillion other warnings... ;-) ) Happy hacking, Finn S. Nielsen Morphologic ApS www.morphologic.dkArticle: 152751
Hi, We have a new board we just designed, and we're trying to fire up the first one. http://www.panoramio.com/photo/60806547 It has an Altera EP2AGX45DF29C5N on board; says so right on the label. When we hook up the JTAG USB Blaster pod and run the Quartus Programmer program, it insists that the chip is a GX65 so it doesn't allow us to load a configuration that was compiled for a GX45. What the heck? Any ideas? JohnArticle: 152752
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:408s97p0dudngepc626tcgbcdu13qsqlt7@4ax.com... > Hi, > > We have a new board we just designed, and we're trying to fire up the > first one. > > http://www.panoramio.com/photo/60806547 > > It has an Altera EP2AGX45DF29C5N on board; says so right on the label. > > When we hook up the JTAG USB Blaster pod and run the Quartus > Programmer program, it insists that the chip is a GX65 so it doesn't > allow us to load a configuration that was compiled for a GX45. > > What the heck? Any ideas? > > John > Missing pull up/down ? I would suspect some Jtag interference with a new device. Do you have the latest Quartus 10 ? Or even the latest usb blaster driver? CheersArticle: 152753
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:408s97p0dudngepc626tcgbcdu13qsqlt7@4ax.com... > Hi, > > We have a new board we just designed, and we're trying to fire up the > first one. > > http://www.panoramio.com/photo/60806547 > > It has an Altera EP2AGX45DF29C5N on board; says so right on the label. > > When we hook up the JTAG USB Blaster pod and run the Quartus > Programmer program, it insists that the chip is a GX65 so it doesn't > allow us to load a configuration that was compiled for a GX45. > > What the heck? Any ideas? > > John > Do you have TCK daisy chained with other devices? It's possible that you have a signal integrity problem on it. This is a fast-edge clock like any other and needs to be treated as such. Can you tell if the other bits in the stream are correct? If you can read them, it would be good to compare them to the BSDL file to see if it's a bit error or if the device is really providing the unexpected value. You can get the BSDL file on the Altera website. Bob -- == All google group posts are automatically deleted due to spam ==Article: 152754
> Do you have the latest Quartus 10 ? The latest one is 11.0sp1, update Your software if You didn't do this already.Article: 152755
On 19.10.2011 4:15, John Larkin wrote: > It has an Altera EP2AGX45DF29C5N on board; says so right on the label. > > When we hook up the JTAG USB Blaster pod and run the Quartus > Programmer program, it insists that the chip is a GX65 so it doesn't > allow us to load a configuration that was compiled for a GX45. Have you checked these few signals mentioned in the manual. I had this problem once in the past. "If the device is in reset state, when the nCONFIG or nSTATUS signal is low, the device IDCODE might not be read correctly. To read the device IDCODE correctly, you must issue the IDCODE JTAG instruction only when the nSTATUS signal is high." --KimArticle: 152756
On Wed, 19 Oct 2011 11:06:04 +0300, Kim Enkovaara <kim.enkovaara@iki.fi> wrote: >On 19.10.2011 4:15, John Larkin wrote: >> It has an Altera EP2AGX45DF29C5N on board; says so right on the label. >> >> When we hook up the JTAG USB Blaster pod and run the Quartus >> Programmer program, it insists that the chip is a GX65 so it doesn't >> allow us to load a configuration that was compiled for a GX45. > >Have you checked these few signals mentioned in the manual. I >had this problem once in the past. > >"If the device is in reset state, when the nCONFIG or nSTATUS signal is >low, the device IDCODE might not be read correctly. To read the device >IDCODE correctly, you must issue the IDCODE JTAG instruction only when >the nSTATUS signal is high." > >--Kim Kim, When you posted that, my reaction was "no, nobody could make the jtag handshake that stupid"... but they did! We wrote a stub program for our ARM processor to just pull up nCONFIG, and now the chip id's itself as a GX45. Thanks! If you're ever in San Francisco, expect free beer. JohnArticle: 152757
The Xilinx USB II cable hangs on a regular basis. I've found that pulling
the USB connector out and putting it back in isn't sufficient, the only
way that I can get Chipscope to see it again is to power cycle the
machine. I'm running SL6.1 (RHEL 6.1). The udev rules are,
# version 0003
ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $tempnode"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0009", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xup.hex -D $tempnode"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $tempnode"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xlp.hex -D $tempnode"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0013", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xp2.hex -D $tempnode"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0015", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xse.hex -D $tempnode"
Is there some change to the udev rules or to setup_pcusb that will fix this?
Article: 152758"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:331u9712mmv9bmoe32nvhe388s68h746kc@4ax.com... > On Wed, 19 Oct 2011 11:06:04 +0300, Kim Enkovaara > <kim.enkovaara@iki.fi> wrote: > >>On 19.10.2011 4:15, John Larkin wrote: >>> It has an Altera EP2AGX45DF29C5N on board; says so right on the label. >>> >>> When we hook up the JTAG USB Blaster pod and run the Quartus >>> Programmer program, it insists that the chip is a GX65 so it doesn't >>> allow us to load a configuration that was compiled for a GX45. >> >>Have you checked these few signals mentioned in the manual. I >>had this problem once in the past. >> >>"If the device is in reset state, when the nCONFIG or nSTATUS signal is >>low, the device IDCODE might not be read correctly. To read the device >>IDCODE correctly, you must issue the IDCODE JTAG instruction only when >>the nSTATUS signal is high." >> >>--Kim > > Kim, > > When you posted that, my reaction was "no, nobody could make the jtag > handshake that stupid"... but they did! > > We wrote a stub program for our ARM processor to just pull up nCONFIG, > and now the chip id's itself as a GX45. > > Thanks! > > If you're ever in San Francisco, expect free beer. > > John > Me too! I'm doing a Stratix V design now. I already have pullups on nConfig and nStatus, but it's great to know about this...ahhh...feature. Thanks, Kim! Bob -- == All google group posts are automatically deleted due to spam ==Article: 152759
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Wed, 19 Oct 2011 11:06:04 +0300, Kim Enkovaara ><kim.enkovaara@iki.fi> wrote: > >>On 19.10.2011 4:15, John Larkin wrote: >>> It has an Altera EP2AGX45DF29C5N on board; says so right on the label. >>> >>> When we hook up the JTAG USB Blaster pod and run the Quartus >>> Programmer program, it insists that the chip is a GX65 so it doesn't >>> allow us to load a configuration that was compiled for a GX45. >> >>Have you checked these few signals mentioned in the manual. I >>had this problem once in the past. >> >>"If the device is in reset state, when the nCONFIG or nSTATUS signal is >>low, the device IDCODE might not be read correctly. To read the device >>IDCODE correctly, you must issue the IDCODE JTAG instruction only when >>the nSTATUS signal is high." >> >>--Kim > >Kim, > >When you posted that, my reaction was "no, nobody could make the jtag >handshake that stupid"... but they did! Isn't it possible to load the FPGA using an SPI like interface? I avoid using JTAG whenever I can. A JTAG interface is not something that is required for a device to function properly so it gets very little attention to get it right. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152760
W dniu 2011-10-19 19:47, General Schvantzkoph pisze:
> The Xilinx USB II cable hangs on a regular basis. I've found that pulling
> the USB connector out and putting it back in isn't sufficient, the only
> way that I can get Chipscope to see it again is to power cycle the
> machine. I'm running SL6.1 (RHEL 6.1). The udev rules are,
>
> # version 0003
> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $tempnode"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0009", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xup.hex -D $tempnode"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $tempnode"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xlp.hex -D $tempnode"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0013", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xp2.hex -D $tempnode"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0015", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xse.hex -D $tempnode"
>
> Is there some change to the udev rules or to setup_pcusb that will fix this?
For Gentoo I must restart udev and cleancablelock:
# udevadm trigger --attr-match=dev
# impact -batch
>cleancablelock
>exit
Article: 152761On Wed, 19 Oct 2011 18:49:30 GMT, nico@puntnl.niks (Nico Coesel) wrote: >John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>On Wed, 19 Oct 2011 11:06:04 +0300, Kim Enkovaara >><kim.enkovaara@iki.fi> wrote: >> >>>On 19.10.2011 4:15, John Larkin wrote: >>>> It has an Altera EP2AGX45DF29C5N on board; says so right on the label. >>>> >>>> When we hook up the JTAG USB Blaster pod and run the Quartus >>>> Programmer program, it insists that the chip is a GX65 so it doesn't >>>> allow us to load a configuration that was compiled for a GX45. >>> >>>Have you checked these few signals mentioned in the manual. I >>>had this problem once in the past. >>> >>>"If the device is in reset state, when the nCONFIG or nSTATUS signal is >>>low, the device IDCODE might not be read correctly. To read the device >>>IDCODE correctly, you must issue the IDCODE JTAG instruction only when >>>the nSTATUS signal is high." >>> >>>--Kim >> >>Kim, >> >>When you posted that, my reaction was "no, nobody could make the jtag >>handshake that stupid"... but they did! > >Isn't it possible to load the FPGA using an SPI like interface? I >avoid using JTAG whenever I can. A JTAG interface is not something >that is required for a device to function properly so it gets very >little attention to get it right. The ARM processor will load the FPGA through its SPI port in real life, but we're using JTAG to test the PCI Express interface parts first, because it's quick and easy. When it works. The production system has the ARM boot its code off a serial flash chip. Then it reads more of that flash chip and configures the FPGA. We'll probably compress the config data, because it's something insane like 30 megabits, mostly zeroes. JohnArticle: 152762
On Wed, 19 Oct 2011 21:47:43 +0200, Bik wrote:
> W dniu 2011-10-19 19:47, General Schvantzkoph pisze:
>> The Xilinx USB II cable hangs on a regular basis. I've found that
>> pulling the USB connector out and putting it back in isn't sufficient,
>> the only way that I can get Chipscope to see it again is to power cycle
>> the machine. I'm running SL6.1 (RHEL 6.1). The udev rules are,
>>
>> # version 0003
>> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666"
>> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd",
>> ATTR{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I
>> /usr/share/xusbdfwu.hex -D $tempnode" SUBSYSTEM=="usb", ACTION=="add",
>> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0009", RUN+="/sbin/fxload -v
>> -t fx2 -I /usr/share/xusb_xup.hex -D $tempnode" SUBSYSTEM=="usb",
>> ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d",
>> RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $tempnode"
>> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd",
>> ATTR{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I
>> /usr/share/xusb_xlp.hex -D $tempnode" SUBSYSTEM=="usb", ACTION=="add",
>> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0013", RUN+="/sbin/fxload -v
>> -t fx2 -I /usr/share/xusb_xp2.hex -D $tempnode" SUBSYSTEM=="usb",
>> ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0015",
>> RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xse.hex -D $tempnode"
>>
>> Is there some change to the udev rules or to setup_pcusb that will fix
>> this?
> For Gentoo I must restart udev and cleancablelock: # udevadm trigger
> --attr-match=dev
> # impact -batch
> >cleancablelock
> >exit
That sounds like what I want. Where do I get dev from? Here is my lsusb
output, which is the field that I should use for dev?
Bus 001 Device 003: ID 03fd:0008 Xilinx, Inc.
Article: 152763> > The ARM processor will load the FPGA through its SPI port in real > life, but we're using JTAG to test the PCI Express interface parts > first, because it's quick and easy. When it works. > > The production system has the ARM boot its code off a serial flash > chip. Then it reads more of that flash chip and configures the FPGA. > We'll probably compress the config data, because it's something insane > like 30 megabits, mostly zeroes. > > John > > I thought Quartus will compress for you ??? Do you need all 30 Mbits ???Article: 152764
On Wed, 19 Oct 2011 21:57:00 +0100, "TTman" <pcw1.cad@ntlworld.com> wrote: >> >> The ARM processor will load the FPGA through its SPI port in real >> life, but we're using JTAG to test the PCI Express interface parts >> first, because it's quick and easy. When it works. >> >> The production system has the ARM boot its code off a serial flash >> chip. Then it reads more of that flash chip and configures the FPGA. >> We'll probably compress the config data, because it's something insane >> like 30 megabits, mostly zeroes. >> >> John >> >> > >I thought Quartus will compress for you ??? Do you need all 30 Mbits ??? > You don't really get a choice. Every config bit and every RAM bit is in the config file. The vendor's compression usually doesn't help a lot. Since most of the config data is 0's, simple bytewise RLL compression on zeroes helps a lot, 2:1 to as much as 5:1. JohnArticle: 152765
Those who've been on this newsgroup for any period of time will remember Peter Alfke, the Xilinx legend, and his infectious enthusiasm. He was a great help as I got into FPGA design 8 years ago, as I embarked on the academic track. I met him at a number of conferences, and he was just as wonderful in person. He gave some real life to the newsgroup and has been sorely missed since he stopped posting. A tweet that carried the news: https://twitter.com/xilinxtraining/status/126857481812066304 Our condolences to his family and friends; he will be sorely missed. Suhaib.Article: 152766
On 20/10/2011 06:33, Suhaib Fahmy wrote: > Those who've been on this newsgroup for any period of time will > remember Peter Alfke, the Xilinx legend, and his infectious > enthusiasm. He was a great help as I got into FPGA design 8 years ago, > as I embarked on the academic track. I met him at a number of > conferences, and he was just as wonderful in person. He gave some real > life to the newsgroup and has been sorely missed since he stopped > posting. > > A tweet that carried the news: https://twitter.com/xilinxtraining/status/126857481812066304 > > Our condolences to his family and friends; he will be sorely missed. > > Suhaib. Indeed quite sad as he was a real guru with a great personality. http://www.eetimes.com/electronics-news/4183358/Pull-up-a-chair-Peter-Alfke Hans www.ht-lab.comArticle: 152767
Sad news. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152768
On 20/10/2011 06:33, Suhaib Fahmy wrote: > Those who've been on this newsgroup for any period of time will > remember Peter Alfke, the Xilinx legend, and his infectious > enthusiasm. He was a great help as I got into FPGA design 8 years ago, > as I embarked on the academic track. I met him at a number of > conferences, and he was just as wonderful in person. He gave some real > life to the newsgroup and has been sorely missed since he stopped > posting. > > A tweet that carried the news: https://twitter.com/xilinxtraining/status/126857481812066304 > > Our condolences to his family and friends; he will be sorely missed. > > Suhaib. He helped me more than once, and was the main reason for my choosing Xilinx. RIP. -- SydArticle: 152769
Suhaib Fahmy <suhaib@fahmy.net> wrote: > >A tweet that carried the news: https://twitter.com/xilinxtraining/status/126857481812066304 So far no official announcement on the Xilinx page. Sure this isn't some sick joke? -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152770
On Oct 20, 9:40=A0am, n...@puntnl.niks (Nico Coesel) wrote: > Suhaib Fahmy <suh...@fahmy.net> wrote: > > >A tweet that carried the news:https://twitter.com/xilinxtraining/status/= 126857481812066304 > > So far no official announcement on the Xilinx page. Sure this isn't > some sick joke? > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > nico@nctdevpuntnl (punt=3D.) > -------------------------------------------------------------- Unfortunately this is not a joke. Ed McGettigan -- Xilinx Inc.Article: 152771
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: >On Oct 20, 9:40=A0am, n...@puntnl.niks (Nico Coesel) wrote: >> Suhaib Fahmy <suh...@fahmy.net> wrote: >> >> >A tweet that carried the news:https://twitter.com/xilinxtraining/status/= >126857481812066304 >> >> So far no official announcement on the Xilinx page. Sure this isn't >> some sick joke? > >Unfortunately this is not a joke. > >Ed McGettigan >Xilinx Inc. Then it is very sad news. My condolences. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152772
> So far no official announcement on the Xilinx page. Sure this isn't > some sick joke? Xilinx's official twitter account has retweeted a number of related tweets. So it seems not=85Article: 152773
Hello I am very new to FPGA's (background being ASIC design). I would like to map some designs onto FPGA's as a starting point. I want to experiment with the complete FPGA flow, starting with writing the design in VHDL/Verilog and getting it programmed onto a target FPGA (it doesn't matter which FPGA for the time being). I was looking for free/cheap FPGA developement s/w what i could run on my home PC and better understand the process of mapping a design to an FPGA target. Any pointers for SW or developement tools would be appreciated. Thanks JOArticle: 152774
> So far no official announcement on the Xilinx page. Sure this isn't > some sick joke? > It seems he had important health problems since long time. I found this on the web http://stanfordhospital.org/newsEvents/newsReleases/2011/provenge-release.html There is no a sure reference which certifies that the "Peter Alfke" on the article is really him (at least reading the article at first glance) but looking to the photo and by comparing with http://www.eetimes.com/electronics-news/4183358/Pull-up-a-chair-Peter-Alfke it seems to be really him. I read many of his articles and note. We will miss him and his passion for job. Fabio
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