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 Sep 1, 11:16=A0am, valtih1978 <d...@not.email.me> wrote: > Your theory proves everything true. It is known as 'determinism'. > > In reality, FPGA tools ensure the data not too late. Because they know > the length of both clock and data. You tell the length of board clock > trace to SDRAM by the feedback. But, there is no information about > DQ/addr delays. Therefore, the on-chip-like timing analysis is > impossible. The external clock feedback makes no sense at all. OK, you make me to rethink about this.. what I'm going to do next is to reroute the DCM not to use external feedback, and see if the sdram still operate correct or not,Article: 152526
Hello Group. I'm currently fighting a custom-designed Virtex-6 XC6VHX380T Master SPI loading problem. Everything seems to go smoothely - Clock and Read command (0x03) is given and the PROM returns data to DIN... But loading never stops at the expected point, clock runs on and of course no Config or Done is reached.... Thus - simple question: Are there anybody here that have a working Master SPI loading of the Virtex-6 XC6VHX380T or similar devices in the same family? Bit data come out of the ISE 13.2 BitGen tool, which have been found to suffer under this "feature": - http://www.xilinx.com/support/answers/40920.htm Currently, we are using these options: -w -g DebugBitstream:No -g CRC:Enable -g ConfigRate:2 -g CclkPin:PullUp -g M0Pin:PullUp -g M1Pin:PullUp -g M2Pin:PullUp -g ProgPin:PullUp -g InitPin:Pullup -g CsPin:Pullup -g DinPin:Pullup -g BusyPin:Pullup -g RdWrPin:Pullup -g HswapenPin:PullUp -g TckPin:PullUp -g TdiPin:PullUp -g TdoPin:PullUp -g TmsPin:PullUp -g Disable_JTAG:No -g UnusedPin:PullDown -g UserID:0xFFFFFFFF -g ConfigFallback:Enable -g BPI_page_size:1 -g OverTempPowerDown:Disable -g next_config_addr:0x00000000 -g JTAG_SysMon:Enable -g DCIUpdateMode:Quiet -g StartUpClk:CClk -g DONE_cycle:4 -g GTS_cycle:5 -g GWE_cycle:6 -g Match_cycle:Auto -g Security:Level1 -g DonePipe:No -g DriveDone:No -g Binary:Yes Are there anything else one should be focused on when setting the -g "options"...? Thanks in advance for your time & best regards, Jesper.Article: 152527
Hi all! Anyone tried using the post-configuration scrubbing function in Spartan-6? I am a little at a loss reading the documentation, so any first-hand experience would be valuable. From the configuration user guide (UG380) I have deduced the following limitations: - INIT_B can not be used as a dual-purpose I/O, even if you set POST_CRC_INIT_FLAG = Disable (UG 380 p 131: "Whether or not the INIT_B pin is used as the error signal, it cannot be used as user I/O when POST_CRC is enabled"). It seems rather silly to even have this option if it does not free up the INIT_B-pin, and from AR#39582 (http:// www.xilinx.com/support/answers/39582.htm), it seems this is a bug that will be documented as a feature. Of course you would have to have some other means of conveying any error to the outside world, it just so happens that in our system this would have been easier to do on a different pin that INIT_B. - What if you use the memory controller? UG380 p 130 says: "Use of the PLL DRP is not masked; therefore, any change to the PLL results in a CRC error". The memory controller is bound to fiddle with the PLL- settings and I assume that is done through the DRP, does that imply that that POST_CRC can not be used if you have an MCB in the system? - The same question is valid for the I/O-block DRPs. UG380 p 130 says: "The I/O interface DRP at the top and bottom can be masked". From that one would guess that the left and right banks IO interface DRP can not be masked, so any tuning of the IOB delays in these would render the CRC invalid, right? It doesn't say how the masking is done either... Any comments? /Lars P.S. Remove the obvious from my address if you want to email me directly. D.S.Article: 152528
On Sep 3, 5:14=A0am, Jesper Kristensen <repse...@gmail.com> wrote: > Hello Group. > > I'm currently fighting a custom-designed Virtex-6 XC6VHX380T Master > SPI loading problem. > Everything seems to go smoothely - Clock and Read command (0x03) is > given and the PROM returns data to DIN... > But loading never stops at the expected point, clock runs on and of > course no Config or Done is reached.... > > Thus - simple question: > Are there anybody here that have a working Master SPI loading of the > Virtex-6 XC6VHX380T or similar devices in the same family? > > Bit data come out of the ISE 13.2 BitGen tool, which have been found > to suffer under this "feature": > > =A0-http://www.xilinx.com/support/answers/40920.htm > > Currently, we are using these options: > > -w > -g DebugBitstream:No > -g CRC:Enable > -g ConfigRate:2 > -g CclkPin:PullUp > -g M0Pin:PullUp > -g M1Pin:PullUp > -g M2Pin:PullUp > -g ProgPin:PullUp > -g InitPin:Pullup > -g CsPin:Pullup > -g DinPin:Pullup > -g BusyPin:Pullup > -g RdWrPin:Pullup > -g HswapenPin:PullUp > -g TckPin:PullUp > -g TdiPin:PullUp > -g TdoPin:PullUp > -g TmsPin:PullUp > -g Disable_JTAG:No > -g UnusedPin:PullDown > -g UserID:0xFFFFFFFF > -g ConfigFallback:Enable > -g BPI_page_size:1 > -g OverTempPowerDown:Disable > -g next_config_addr:0x00000000 > -g JTAG_SysMon:Enable > -g DCIUpdateMode:Quiet > -g StartUpClk:CClk > -g DONE_cycle:4 > -g GTS_cycle:5 > -g GWE_cycle:6 > -g Match_cycle:Auto > -g Security:Level1 > -g DonePipe:No > -g DriveDone:No > -g Binary:Yes > > Are there anything else one should be focused on when setting the -g > "options"...? > > Thanks in advance for your time & best regards, > > =A0 Jesper. Hi Jesper, Change the next_config_addr to this: -g next_config_addr:None That seemed to do the trick for me. Apparently, there was a bug in 13.1 and the bitgen options needed to be tweaked in order to generate a good bit and mcs file. Thanks, JeremyArticle: 152529
PSD to XHTML Conversion - xhtmlchamps - provides psd to html, psd to joomla, wordpress, drupal, cms, vbulletin, phpbb conversion, psd to xhtml css services. Includes web designing services, logos, banner design, website building, animation, presentations. for more details: http://www.xhtmlchamps.comArticle: 152530
Hello everyone, Recently I installed Xilinx ISE Design Suit 13.1 for studying. I got the licence right and everything, but unfortunately I faced a few strange problems... First of all, I can't run all the tools. So far I've succesfully ran Plan Ahead and EDK SDK but I can't open neiter EDK Xilinx Platform Studio (XPS) nor ISE Project Navigator. When i want to run it through Start Menu (or click on the shortcut), only a black MS-Dos window shows up for a second and after that nothing happens. What's more, I can't even uninstall the software now... when I click "uninstall" nothing happens at all. Any idea what could be the problem and how to solve it? Thanks in advance! Z.Article: 152531
is xilinx platform usb jtag supports non-xilinx devices regards salim --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152532
salimbaba <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > is xilinx platform usb jtag supports non-xilinx devices There is a cable plugin API, that e.g. Digilent uses, but the API seems to be non-public. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 152533
On Sep 6, 3:09=A0am, jwwebb <jww...@jwebb-design.com> wrote: > On Sep 3, 5:14=A0am, Jesper Kristensen <repse...@gmail.com> wrote: > > > > > > > > > > > Hello Group. > > > I'm currently fighting a custom-designed Virtex-6 XC6VHX380T Master > > SPI loading problem. > > Everything seems to go smoothely - Clock and Read command (0x03) is > > given and the PROM returns data to DIN... > > But loading never stops at the expected point, clock runs on and of > > course no Config or Done is reached.... > > > Thus - simple question: > > Are there anybody here that have a working Master SPI loading of the > > Virtex-6 XC6VHX380T or similar devices in the same family? > > > Bit data come out of the ISE 13.2 BitGen tool, which have been found > > to suffer under this "feature": > > > =A0-http://www.xilinx.com/support/answers/40920.htm > > > Currently, we are using these options: > > > -w > > -g DebugBitstream:No > > -g CRC:Enable > > -g ConfigRate:2 > > -g CclkPin:PullUp > > -g M0Pin:PullUp > > -g M1Pin:PullUp > > -g M2Pin:PullUp > > -g ProgPin:PullUp > > -g InitPin:Pullup > > -g CsPin:Pullup > > -g DinPin:Pullup > > -g BusyPin:Pullup > > -g RdWrPin:Pullup > > -g HswapenPin:PullUp > > -g TckPin:PullUp > > -g TdiPin:PullUp > > -g TdoPin:PullUp > > -g TmsPin:PullUp > > -g Disable_JTAG:No > > -g UnusedPin:PullDown > > -g UserID:0xFFFFFFFF > > -g ConfigFallback:Enable > > -g BPI_page_size:1 > > -g OverTempPowerDown:Disable > > -g next_config_addr:0x00000000 > > -g JTAG_SysMon:Enable > > -g DCIUpdateMode:Quiet > > -g StartUpClk:CClk > > -g DONE_cycle:4 > > -g GTS_cycle:5 > > -g GWE_cycle:6 > > -g Match_cycle:Auto > > -g Security:Level1 > > -g DonePipe:No > > -g DriveDone:No > > -g Binary:Yes > > > Are there anything else one should be focused on when setting the -g > > "options"...? > > > Thanks in advance for your time & best regards, > > > =A0 Jesper. > > Hi Jesper, > > Change the next_config_addr to this: > > -g next_config_addr:None > > That seemed to do the trick for me. Apparently, there was a bug in > 13.1 and the bitgen options needed to be tweaked in order to generate > a good bit and mcs file. > > Thanks, > > Jeremy Thanks a lot, Jeremy! That did the trick for me, too! As I suggested above, I was aware of this bitgen "flaw" and had pointed it out to my IP vendor... Unfortunately, they have only little experience with Xilinx, so they thought they had their foot on it... But that's life, I guess. ;-) Thanks again - Jesper.Article: 152534
Dear Gurus; I have 1 Cyclone IV GX EP4CGX150(DF27C7) This Cyclone IV is connected to 6 x Cyclone III (C40F484) All of these 6 Cyclone IIIs will send 4 bit LVDS serialized input data and a clock(120mhz) I need to deserialize 4 bits of data with their respective clocks by Cyclone IV GXEP4CGX150 Questions 1- Which banks should I use for these 30pins (4 bit data and clock inputs) x6 2- What is the number of PLLs that I need to use while desialization PS: I used to do this with Xilinx Spartan 6 but I am new to Altera.Article: 152535
Hello, i'm working on microblaze project (using ISE 10.1) and obviously adding peripheral the EDK synthesis takes a long time. There's a method or tool to improve this time?? I've tried the -smartguide switch but it doesn't work, i'm trying using partition. Have you any regard? Sorry for my english i'm foreign. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152536
Hi, i usually do ROM merge using Data2mem, but this time my design use RAMB18x2 inside it they split it for RAMB18_Upper and RAMB18_Lower, but RAM instance remain same for both RAMB18_upper and RAMB18_lower, so ! time of DATA2mem i am getting error message "DATA2MEM - duplicate instance name usage in address space 'Program_Memory2'" please help me Thanks lilaisgr8 --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152537
On 5 Sep, 14:34, Lars <noreply.lar...@gmail.com> wrote: > Hi all! > Anyone tried using the post-configuration scrubbing function in > Spartan-6? I am a little at a loss reading the documentation, so any > first-hand experience would be valuable. From the configuration user > guide (UG380) I have deduced the following limitations: > > - INIT_B can not be used as a dual-purpose I/O, even if you set > POST_CRC_INIT_FLAG =3D Disable (UG 380 p 131: "Whether or not the INIT_B > pin is used as the error signal, it cannot be used as user I/O when > POST_CRC is enabled"). It seems rather silly to even have this option > if it does not free up the INIT_B-pin, and from AR#39582 (http://www.xili= nx.com/support/answers/39582.htm), it seems this is a bug that > will be documented as a feature. Of course you would have to have some > other means of conveying any error to the outside world, it just so > happens that in our system this would have been easier to do on a > different pin that INIT_B. > > - What if you use the memory controller? UG380 p 130 says: "Use of the > PLL DRP is not masked; therefore, any change to the PLL results in a > CRC error". The memory controller is bound to fiddle with the PLL- > settings and I assume that is done through the DRP, does that imply > that that POST_CRC can not be used if you have an MCB in the system? > > - The same question is valid for the I/O-block DRPs. =A0UG380 p 130 > says: "The I/O interface DRP at the top and bottom can be masked". > From that one would guess that the left and right banks IO interface > DRP can not be masked, so any tuning of the IOB delays in these would > render the CRC invalid, right? It doesn't say how the masking is done > either... > > Any comments? > /Lars > > P.S. Remove the obvious from my address if you want to email me > directly. D.S. Hi again! No one out there who have given it a try? I have now gotten as far as instantiating the post_crc_internal and hooking it up to an external pin, as well as a ChipScope ILA. They where not kidding about the INIT_B-pin, I could P&R with it used as an I/O, but BitGen threw an error unless I left it unconnected. I didn't have to use the "-g persist" switch though, so all of the other dual-purpose configuration pins could still be used as I/O. It didn't seem to work as good in practice though, Impact immediately gave a warning saying "CRC error bit is NOT 0", and ChipScope shows the crcerror output high from post_crc_internal, so I still have no idea if this has any potential to work. Good thing is the application seems to work though (minus the pin that doubles for INIT_B). I haven't been able to hook up an oscilloscope to measure the crcerror output in respect to e.g .DONE, maybe I can get around to that later. That might give some insight. I guess I will have to pester my XILINX FAE some more, maybe the I/O DRP and/or MCB PLL d.o. are killers. Cheers! /LarsArticle: 152538
On 8 sep, 07:39, "catto" <catto.15@n_o_s_p_a_m.hotmail.it> wrote: > Hello, > i'm working on microblaze project (using ISE 10.1) and obviously adding > peripheral the EDK synthesis takes a long time. > There's a method or =C2=A0tool to improve this time?? > I've tried the -smartguide switch but it doesn't work, i'm trying using > partition=EF=BB=BF. Have you any regard? > Sorry for my english i'm foreign. > > --------------------------------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Posted throughhttp://www.FPGARelated.com ISE 13.1 is much faster than ISE 10.1 so if you're starting a new design you might consider using ISE 13.1 Furthermore, Xilinx has improved EDK a lot.Article: 152539
I would say that for synthesis in general, the speedup is about 2x between version 10.1 and 13.1Article: 152540
On 09/09/2011 06:43 AM, Benjamin Couillard wrote: > I would say that for synthesis in general, the speedup is about 2x > between version 10.1 and 13.1 EDK 13.2 now also adds support for parallel synthesis, which can give a big speed up if your computer has more than one CPU. You can enable it from: XPS->Preferences->Synthesis->[x]Parallel Synthesis Nice feature :) Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.au $39 Spartan 6 board with 32MB DDR DRAM ? http://www.sioi.com.au/shop/product_info.php/products_id/47Article: 152541
On 09/08/2011 09:40 PM, lilaisgr8 wrote: > Hi, > > i usually do ROM merge using Data2mem, but this time my design use > RAMB18x2 > inside it they split it for RAMB18_Upper and RAMB18_Lower, but RAM instance > remain same for both RAMB18_upper and RAMB18_lower, so ! time of DATA2mem i > am getting error message "DATA2MEM - duplicate instance name usage in > address space 'Program_Memory2'" > > please help me > > Thanks > lilaisgr8 Sounds like a tricky problem ... you should try posting at the Xilinx community forums: http://forums.xilinx.com/ There many more Xilinx experts there, including Xilinx employees. Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.au $39 Spartan 6 board with 32MB DDR DRAM ? http://www.sioi.com.au/shop/product_info.php/products_id/47Article: 152542
"salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> writes: > is xilinx platform usb jtag supports non-xilinx devices I've used some of the Xilinx cables to program other devices through JTAG using SVF files. //Petter -- .sig removed by request.Article: 152543
salimbaba <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > is xilinx platform usb jtag supports non-xilinx devices With sourceforge svn xc3sprog could can programm AVR and AVR XMEGA with the DLC9/10. Urjtag and openocd know also the DLC9/10 -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 152544
Hi I guess I am alone with the issue, but asking still :) board(s) working ok, FPGA in SDM mode. suddenly after some repramming FPGA 1) goes HOT, reads bad JTAG ID, can be restored to live by changing CFG mode and erasing 2) does not go hot, but reads 0's as JTAG ID, can not be restored, setting CFG0=CFG1=PROGRAMN=0 (GND) still yields 0 JTAG ID and to my surprise the NOT CONFIGURED FPGA seems to DRIVE regular IO (should be tristated unless FPGA configured) any body had any issue? please reply with any similar issue being seen ever. to groups or in private AnttiArticle: 152545
Antti <antti.lukats@googlemail.com> wrote: > Hi > > I guess I am alone with the issue, but asking still :) > > board(s) working ok, FPGA in SDM mode. > suddenly after some repramming FPGA > > 1) goes HOT, reads bad JTAG ID, can be restored to live by changing CFG mode and erasing > > 2) does not go hot, but reads 0's as JTAG ID, can not be restored, setting CFG0=CFG1=PROGRAMN=0 (GND) still yields 0 JTAG ID and to my surprise the NOT CONFIGURED FPGA seems to DRIVE regular IO (should be tristated unless FPGA configured) > > any body had any issue? > please reply with any similar issue being seen ever. > to groups or in private I've seen this once on an XP2-8E device on which the on-chip Flash was not properly programmed, while I was experimenting with self-devised JTAG bit-banging hw / sw design, which didn't work quite right. Can you read back the bitstream from the on-chip Flash and verify that it is really 100% OK? Does the design work if downloaded directly to SRAM, leaving the on-chip Flash untouched / erased? MarkoArticle: 152546
Hi thanks a lot for reply - but the issue is that JTAG ID is being read back as 00000000 so we can do anything.. all VME functions BAIL out if initial ID verify fails. We are using VME ver 12 player on custom ARM9 linux system. well we could strip out ID verify from SVF file and regenerate the VME files from patched SVF. AnttiArticle: 152547
Antti <antti.lukats@googlemail.com> wrote: > Hi > > thanks a lot for reply - but the issue is that JTAG ID is being read back as 00000000 so we can do anything.. all VME functions BAIL out if initial ID verify fails. We are using VME ver 12 player on custom ARM9 linux system. > > well we could strip out ID verify from SVF file and regenerate the VME files from patched SVF. When I was faced with a similar issue, my device drained more current than the USB port to which it was hooked to could provide. I apparently had some luck by hooking the FPGA to a better power supply, just long enough to have it properly respond to JTAG commands and have the on-chip Flash erased. The chip got really hot during the process, but still works OK today. If all else fails, perhaps you could try to power up the chip with only VCCJTAG provided, while disconnecting the I/O and core (1.2 V) VCC. I don't know if this is out of the specs, but if you already proclaimed the chip to be dead you might try this out and let us know the outcome :) I think the moral of the story is that one should be really careful with programming the on-chip Flash on XP2 devices, otherwise I really like those chips a lot. MarkoArticle: 152548
Antti <antti.lukats@googlemail.com> wrote: > Hi > > thanks a lot for reply - but the issue is that JTAG ID is being read back as 00000000 so we can do anything.. all VME functions BAIL out if initial ID verify fails. We are using VME ver 12 player on custom ARM9 linux system. > > well we could strip out ID verify from SVF file and regenerate the VME files from patched SVF. I guess you could also try to pull down the INITN pin, in addition to having CFG0 & CFG1 grounded, in an attempt to prevent the device to autoconfigure from a (suspected bad) bitstream stored in the on-chip Flash. From specs it is not clear whether pulling down the PROGRAMN pin is sufficient to prevent the device from autoconfiguring. MarkoArticle: 152549
ok, yes, the programn/initn are bit confusing, I have some more interesting results: IR readback 0x19 bits 1,0 are as per JEDEC 1149.1 so JTAG chain is NOT DEAD CFG0=CFG1=PROGRAMN=0(gnd) JTAG ID readback 0x00000000 CFG0=CFG1=PROGRAMN=1(open) JTAG ID readback 0xFFFFFFFF in both cases the ERASE seems to work as normal, eg it does poll a few times, and get erase done flag ok. but the chip still seems to be configured from bad flash as it never tristates its IO pins :( -- HOT, yes I had one chip that got hot, and was still possible to reflash and erase and worked well after Antti
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