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
Not sure if this answers your question... but it uses whatever UCF file you add to the ISE project when you do an "Add source file".... so if you've got an FX12 project and an SX35 project running outta the same directory you can have then referencing different UCF files, yes..... If you're meaning that you want to have it automatically associate with a given UCF file, depending upon what part you select when you begin a *new* project.... as far as I know, no. Just out of curiousity, what's your application that makes this behavior desireable? In my experience UCF files tend to be fairly application specific..... Multiple projects with the same pinout I take it? Brad Smallridge wrote: > Is there any way to switch from a ucf file for > an ML402 dev board to a ucf file for a ML403 > board without having to delete one file from > the project and copy the source from another > ucf file? Can it automatically know what ucf > file to use based on the FX12 or SX35 part? > > Brad Smallridge > aivision > dot > comArticle: 111751
yea... if you've got the actual abel code, not just the "synthesized" JED file, you're probably better off rewriting the VHDL. I can't imagine that anything that was originally written in ABEL is so complicated that it'd take more than a couple hours to rewrite.... if i'm not mistaken devices were pretty small back when folks where using abel, so it can't feasibly be ALL that much logic to recode. Jonathan Bromley wrote: > On 8 Nov 2006 23:15:29 -0800, lingamaneni.naveen@gmail.com wrote: > > >I have a JED file for an old PAL device and I have to put this design > >in a FPGA. > > JED != ABEL. You have only the fusemap! > > >Is there a tool that can read the JED file and translate it to any > >usable language (VHDL prefered)... > > Yup. It's a sloppy bag of fats and proteins suspended in > salty water, and it sits between your ears. > > But being just a little more helpful.... > > It is not too difficult to construct a VHDL *netlist* from a > fusemap and a description of the target PAL device, > although I'm not aware of any off-the-shelf tools to do it. > That could give you a simulation model, but it does NOT give you > a behavioural model that would allow you to understand and > modify the functionality. With your knowledge > of the device's intended functionality and the simulation model, > you could write a testbench to exercise it, check out the fine > details of its behaviour and use that information to do the > reverse engineering. > > If the PAL is purely combinatorial (PAL16L8 etc) then you could > construct a truth table. If it's a registered device (PAL16R8, > 22V10...) then it's a bit harder. In PAL devices register resources > were scarce, and designers used all manner of ingerious tricks > to cram in the logic; that usually meant obscuring the distinction > between control and datapath, so reverse engineering > could be fun. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.bromley@MYCOMPANY.com > http://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Article: 111752
The information I pointed out is for the on-chip BlockRAM. ScottNortman wrote: > Are you referring to the on-chip block RAM or the attached SDRAM on the > sp3e board? > > > John_H wrote: >> Please look at the Spartan3E Starter Kit webpage >> >> http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-SK-US >> >> where, under the _Documentation_ heading you'll find the User Guide and the >> Reference Designs. The reference design includes a PicoBlaze with a memory >> loader that has both Verilog (or perhaps VHDL) source and an external >> utility to load the memory dynamically. The Picoblaze assembler will also >> generate a file that can be used as INITs in your BlockRAM instantiation. >> The JTAG related updates should be the same for Spartan3 as it is for the >> 3E. >> >> There are other memory-only update tools from Xilinx that might be easier. >> Search the Xilinx site (or Answers Database) for "coe" which is the memory >> file formate used for post-compiled memory updates. >> >> >> "Jialin" <jiaojialin@gmail.com> wrote in message >> news:1163025444.476315.65650@m73g2000cwd.googlegroups.com... >>> Thank you very much for your help. >>> >>> But I want to load data/program into the SRAM of that board, >>> do you know how can I do that? >>> >>> Thanks again. >>> >>> On Nov 7, 7:22 pm, "John_H" <newsgroup@johnhandwork.com> wrote: >>>> If, on the other hand, you have a picoBlaze or MicroBlaze for which you >>>> want >>>> to update the memory, the Spartan3E Starter Kit has that ready to go. >>>> Source code is available. >>>> >>>> "Matthew Hicks" <mdhicks2@uiuc.edu> wrote in >>>> messagenews:eiqq83$819$1@news.ks.uiuc.edu... >>>> >>>> >>>> >>>>> If you are talking about the EEPROM or any other non-volatile on-board >>>>> memory, it should be detected by Impact. Just create an PROM file >>>>> (.mcs) >>>>> from the .bit file and load it into the memory. All of this can be >>>>> done >>>>> inside impact and should be detailed in the user manual for your board. >>>>> ---Matthew Hicks >>>>> "Jialin" <jiaojialin@gmail.com> wrote in message >>>>> news:1162913626.614634.231140@m73g2000cwd.googlegroups.com... >>>>>> Hi my friends, >>>>>> We know little about Spartan and Xilinx. We are connecting our >>>>>> Spartan 3 starter kit board to a PC and using Xilinx ISE 8.1 to >>>>>> control >>>>>> it. >>>>>> We want to find a way to load our program ( instructions) into the >>>>>> memory of >>>>>> the Spartan board. Could you tell me how? We will appreciate it if you >>>>>> could kindly show some light on this.- Hide quoted text -- Show quoted >>>>>> text - >Article: 111753
A long time ago, I found some VHDL models of PALS that used text_io to read the jedec file, and built a constant array that was used to drive a huge generate tree that built up all the and/or gates and flops, etc. The neat thing about it was that the text-io stuff all ran at elaboration time. Too bad synthesis tools cannot make that distinction, and allow text-io for static purposes. If you find them (it has been a long time since then) you might use them as an guide for converting the fusemap to a vhdl package file (with a perl or c app, etc.) that defines the constant, and then the model could be modified to reference the package constant. You might even be able to simply edit the jedec file to turn it into a string array constant definition, and then write vhdl that would convert that into the constant format used by the model. Just an idea... Andy lingamaneni.naveen@gmail.com wrote: > I have a JED file for an old PAL device and I have to put this design > in a FPGA. > Is there a tool that can read the JED file and translate it to any > usable language (VHDL prefered)...Article: 111754
Paul wrote: > yea... if you've got the actual abel code, not just the "synthesized" > JED file, you're probably better off rewriting the VHDL. I can't > imagine that anything that was originally written in ABEL is so > complicated that it'd take more than a couple hours to rewrite.... if > i'm not mistaken devices were pretty small back when folks where using > abel, so it can't feasibly be ALL that much logic to recode. > > This goes back a long time, but I remember that MachXL software from AMD used to be able to reconstruct source from a .JED file. This required a .JED that contained the symbol table (signal names) to end up with something readable. It unfortunately showed your equations in sum-of-products just the way it went into the PAL, not the pre-compiled source. If you really have Abel code and not just the JEDEC file, it is my understanding that Xilinx still supports Abel for anything but top level code modules. I still have designs using Abel in lower level modules, but those are supported with the older Foundation 4.1i tools, so I'm not sure you could use them in newer ISE projects. HTH, GaborArticle: 111755
maxascent wrote: > Hi > > I have an 18-bit bus to a ZBT memory but when I P&R it in Xilinx it sets > half the bus to TRISTATE and the other to BIDIR. Is this to do with the IO > placement or something else? In Synplify they all come up as IOBUF > > Cheers > > J I'd check the map report to see if the TRISTATE half of the bus lost its input path due to removed (optimised away) logic. Sometimes logic is removed due to lack of visible outputs from some other logic further down the line, so it wouldn't be obvious at first that the logic is "unnecessary".Article: 111756
Hej Johan, Do you have a file called xmd_<microblaze_instance_name>.opt in the directory download? replace <microblaze_instance_name> with the name of the microblaze instance from the .mhs file. It can contain automatically settings which mess up the XMD communication. This file get automatically used if you click on the XMD icon in XPS. MVH Göran <e8johan@gmail.com> wrote in message news:1163077412.628583.110960@m73g2000cwd.googlegroups.com... > Hi all, > > I've been struggling for two days now to get xapp730 from Xilinx to > work. I've built the hw (wo FSL as it seems to be confusing the > debugger) and can communicated with the CPU via xmd. However, the dow > command seems to be failing. See transcript of xmd session below. > > Any help or input is very much apprechiated. > > Best regards, > > Johan Thelin > > --- 8< --- > Address Map for Processor microblaze_0 > (0x00000000-0x00001fff) dlmb_cntlr dlmb > (0x00000000-0x00001fff) ilmb_cntlr ilmb > (0x24000000-0x27ffffff) DDR_SDRAM_64Mx32 mb_opb > (0x24000000-0x27ffffff) DDR_SDRAM_64Mx32 ixcl > (0x24000000-0x27ffffff) DDR_SDRAM_64Mx32 dxcl > (0x40000000-0x4000ffff) LEDs_4Bit mb_opb > (0x40020000-0x4002ffff) Push_Buttons_Position mb_opb > (0x40600000-0x4060ffff) RS232_Uart mb_opb > (0x40800000-0x4080ffff) IIC_EEPROM mb_opb > (0x40c00000-0x40c0ffff) Ethernet_MAC mb_opb > (0x41200000-0x4120ffff) opb_intc_0 mb_opb > (0x41400000-0x4140ffff) debug_module mb_opb > (0x41800000-0x4180ffff) SysACE_CompactFlash mb_opb > (0x41c00000-0x41c0ffff) opb_timer_1 mb_opb > > Connecting to cable (Parallel Port - LPT1). > Checking cable driver. > Driver windrvr6.sys version = 7.0.0.0.No resources. > LPT base address = 0378h. > ECP base address = 0778h. > Cable connection failed. > Connecting to cable (Parallel Port - LPT1). > Checking cable driver. > Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h. > ECP base address = 0778h. > Cable connection failed. > Connecting to cable (Parallel Port - LPT2). > Checking cable driver. > Driver windrvr6.sys version = 7.0.0.0.Cable connection failed. > Connecting to cable (Parallel Port - LPT2). > Checking cable driver. > Driver windrvr6.sys version = 7.0.0.0.Cable connection failed. > Connecting to cable (Usb Port - USB22). > Checking cable driver. > Driver xusbdfwu.sys version: 1021 (1021). > Driver windrvr6.sys version = 7.0.0.0.Calling setinterface num=0, > alternate=0. > DeviceAttach: received and accepted attach for: > vendor id 0x3fd, product id 0x8, device handle 0x16726b4 > Cable PID = 0008. > Max current requested during enumeration is 280 mA. > Cable Type = 3, Revision = 0. > Setting cable speed to 6 MHz. > Cable connection established. > Firmware version = 1021. > CPLD file version = 0012h. > CPLD version = 0012h. > > JTAG chain configuration > -------------------------------------------------- > Device ID Code IR Length Part Name > 1 0a001093 8 System_ACE > 2 05059093 16 XCF32P > 3 01e58093 10 XC4VFX12 > 4 09608093 8 xc95144xl > Assuming, Device No: 3 contains the MicroBlaze system > Connected to the JTAG MicroProcessor Debug Module (MDM) > No of processors = 1 > > MicroBlaze Processor 1 Configuration : > ------------------------------------- > Version............................5.00.a > No of PC Breakpoints...............2 > No of Read Addr/Data Watchpoints...0 > No of Write Addr/Data Watchpoints..0 > Instruction Cache Support..........on > Instruction Cache Base Address.....0x24000000 > Instruction Cache High Address.....0x27ffffff > Data Cache Support.................on > Data Cache Base Address............0x24000000 > Data Cache High Address............0x27ffffff > Exceptions Support................off > FPU Support.......................off > FSL DCache Support.................on > FSL ICache Support.................on > Hard Divider Support...............on > Hard Multiplier Support............on > Barrel Shifter Support.............on > MSR clr/set Instruction Support....on > Compare Instruction Support........on > PVR Supported......................off > JTAG MDM Connected to MicroBlaze 1 > Connected to "mb" target. id = 0 > Starting GDB server for "mb" target (id = 0) at TCP port no 1234 > XMD% state > Connected targets state > > Target ID State Target Type > ---------------------------------------------------------- > 0 Stopped MicroBlaze MDM-based (hw) Target > XMD% mrd 0x24000000 100 > 24000000: FFFFFDFF > 24000004: FFFFFFFF > 24000008: FFFFFFFF > 2400000C: FFFFFEFF > 24000010: FFDFFFFF > 24000014: FFFFFFFF > 24000018: FFFFFFFF > 2400001C: FFFFFFFF > 24000020: FFFFFFFF > 24000024: FFFF7FFF > 24000028: BFFFFBFF > 2400002C: FFFFFFFF > 24000030: FFFFF7FF > 24000034: FFFFFFFF > 24000038: FFFFFFFE > 2400003C: FFFFFFFF > 24000040: FFFFFDFF > 24000044: FFFFFFF7 > 24000048: FFFFFFFF > 2400004C: FFFFFFFF > 24000050: FFFF7FFF > 24000054: FFFFFFFF > 24000058: FFFFBFFF > 2400005C: FFFFFFFF > 24000060: FFFFFFFF > 24000064: FFFFFFFF > 24000068: FFFFFBFF > 2400006C: FFFFFFFF > 24000070: FFFFDDFF > 24000074: FFFFF7FF > 24000078: FFFFFFFF > 2400007C: FFFFFFFF > 24000080: FFFFFFFF > 24000084: 7FFFFFFF > 24000088: FFFFFFFF > 2400008C: FFFFFFFF > 24000090: FDFFFFFF > 24000094: FFFFFFFF > 24000098: FFFFFFFF > 2400009C: FFFFFFFF > 240000A0: FFFFFFFF > 240000A4: FFFFFFFF > 240000A8: FFFFFFFF > 240000AC: FFFFFFFF > 240000B0: FFFF7FFD > 240000B4: FFFFFFFF > 240000B8: BFFFFFFF > 240000BC: BFFFFFFF > 240000C0: FFFFFFFF > 240000C4: FFFFF77F > 240000C8: FFFFFBFF > 240000CC: FFFFFFFF > 240000D0: FFDFFFFF > 240000D4: FFFFFFFF > 240000D8: FFFEFFFF > 240000DC: FFFFFFBF > 240000E0: FFFFFFFF > 240000E4: FFFFFFDF > 240000E8: FFFFFBFF > 240000EC: FBFFFFFF > 240000F0: FFFFFFFF > 240000F4: FFFFFFFF > 240000F8: FFFFFFFF > 240000FC: FFFFFFFF > 24000100: FFFFFFFF > 24000104: FFDFFFFF > 24000108: FFEFFBFF > 2400010C: FFFFFFFF > 24000110: FFFFFFFF > 24000114: F7FFFFFF > 24000118: FFFFFFFF > 2400011C: FFFFFFFF > 24000120: FFFFFFFF > 24000124: FFF7FFDF > 24000128: FFFFFFFF > 2400012C: FFFFFFFF > 24000130: FFFFFFFF > 24000134: FFFFFFFF > 24000138: FFFFFBFF > 2400013C: FFFFFFFF > 24000140: FFFFDFFF > 24000144: FFFFFFFF > 24000148: BFFFFFFF > 2400014C: FEFFFFFF > 24000150: FFFFFFFF > 24000154: FFFFFFFF > 24000158: FFFFFFFF > 2400015C: EFFFFFFF > 24000160: FFFFFFFF > 24000164: FFFFFFFF > 24000168: FFFFBEFF > 2400016C: FFFFFFFF > 24000170: FFFFFDFF > 24000174: FFFFFFFF > 24000178: FFFFFFFF > 2400017C: FFFFFFFF > 24000180: FFFFFFFF > 24000184: FFFFFDFF > 24000188: FFFFFEFF > 2400018C: FFFFFFFF > > XMD% mwr 0x24000000 1 > XMD% mrd 0x24000000 1 > 24000000: 00000001 > > XMD% dow -data image.bin 0x24000000 > XMD% mrd 0x24000000 100 > 24000000: 00000001 > 24000004: FFFFFFFF > 24000008: FFFFFFFF > 2400000C: FFFFFEFF > 24000010: FFDFFFFF > 24000014: FFFFFFFF > 24000018: FFFFFFFF > 2400001C: FFFFFFFF > 24000020: FFFFFFFF > 24000024: FFFF7FFF > 24000028: BFFFFBFF > 2400002C: FFFFFFFF > 24000030: FFFFF7FF > 24000034: FFFFFFFF > 24000038: FFFFFFFE > 2400003C: FFFFFFFF > 24000040: FFFFFDFF > 24000044: FFFFFFF7 > 24000048: FFFFFFFF > 2400004C: FFFFFFFF > 24000050: FFFF7FFF > 24000054: FFFFFFFF > 24000058: FFFFBFFF > 2400005C: FFFFFFFF > 24000060: FFFFFFFF > 24000064: FFFFFFFF > 24000068: FFFFFBFF > 2400006C: FFFFFFFF > 24000070: FFFFDDFF > 24000074: FFFFF7FF > 24000078: FFFFFFFF > 2400007C: FFFFFFFF > 24000080: FFFFFFFF > 24000084: 7FFFFFFF > 24000088: FFFFFFFF > 2400008C: FFFFFFFF > 24000090: FDFFFFFF > 24000094: FFFFFFFF > 24000098: FFFFFFFF > 2400009C: FFFFFFFF > 240000A0: FFFFFFFF > 240000A4: FFFFFFFF > 240000A8: FFFFFFFF > 240000AC: FFFFFFFF > 240000B0: FFFF7FFD > 240000B4: FFFFFFFF > 240000B8: BFFFFFFF > 240000BC: BFFFFFFF > 240000C0: FFFFFFFF > 240000C4: FFFFF77F > 240000C8: FFFFFBFF > 240000CC: FFFFFFFF > 240000D0: FFDFFFFF > 240000D4: FFFFFFFF > 240000D8: FFFEFFFF > 240000DC: FFFFFFBF > 240000E0: FFFFFFFF > 240000E4: FFFFFFDF > 240000E8: FFFFFBFF > 240000EC: FBFFFFFF > 240000F0: FFFFFFFF > 240000F4: FFFFFFFF > 240000F8: FFFFFFFF > 240000FC: FFFFFFFF > 24000100: FFFFFFFF > 24000104: FFDFFFFF > 24000108: FFEFFBFF > 2400010C: FFFFFFFF > 24000110: FFFFFFFF > 24000114: F7FFFFFF > 24000118: FFFFFFFF > 2400011C: FFFFFFFF > 24000120: FFFFFFFF > 24000124: FFF7FFDF > 24000128: FFFFFFFF > 2400012C: FFFFFFFF > 24000130: FFFFFFFF > 24000134: FFFFFFFF > 24000138: FFFFFBFF > 2400013C: FFFFFFFF > 24000140: FFFFDFFF > 24000144: FFFFFFFF > 24000148: BFFFFFFF > 2400014C: FEFFFFFF > 24000150: FFFFFFFF > 24000154: FFFFFFFF > 24000158: FFFFFFFF > 2400015C: EFFFFFFF > 24000160: FFFFFFFF > 24000164: FFFFFFFF > 24000168: FFFFBEFF > 2400016C: FFFFFFFF > 24000170: FFFFFDFF > 24000174: FFFFFFFF > 24000178: FFFFFFFF > 2400017C: FFFFFFFF > 24000180: FFFFFFFF > 24000184: FFFFFDFF > 24000188: FFFFFEFF > 2400018C: FFFFFFFF > > XMD% > > --- >8 --- >Article: 111757
Hej Johan, Forgot to tell you to delete or rename that file if you have it. MVH Göran "Göran Bilski" <goran.bilski@xilinx.com> wrote in message news:eivg4m$qr02@cnn.xsj.xilinx.com... > Hej Johan, > > Do you have a file called xmd_<microblaze_instance_name>.opt in the > directory download? > replace <microblaze_instance_name> with the name of the microblaze > instance from the .mhs file. > It can contain automatically settings which mess up the XMD communication. > This file get automatically used if you click on the XMD icon in XPS. > > MVH > Göran > > > <e8johan@gmail.com> wrote in message > news:1163077412.628583.110960@m73g2000cwd.googlegroups.com... >> Hi all, >> >> I've been struggling for two days now to get xapp730 from Xilinx to >> work. I've built the hw (wo FSL as it seems to be confusing the >> debugger) and can communicated with the CPU via xmd. However, the dow >> command seems to be failing. See transcript of xmd session below. >> >> Any help or input is very much apprechiated. >> >> Best regards, >> >> Johan Thelin >> >> --- 8< --- >> Address Map for Processor microblaze_0 >> (0x00000000-0x00001fff) dlmb_cntlr dlmb >> (0x00000000-0x00001fff) ilmb_cntlr ilmb >> (0x24000000-0x27ffffff) DDR_SDRAM_64Mx32 mb_opb >> (0x24000000-0x27ffffff) DDR_SDRAM_64Mx32 ixcl >> (0x24000000-0x27ffffff) DDR_SDRAM_64Mx32 dxcl >> (0x40000000-0x4000ffff) LEDs_4Bit mb_opb >> (0x40020000-0x4002ffff) Push_Buttons_Position mb_opb >> (0x40600000-0x4060ffff) RS232_Uart mb_opb >> (0x40800000-0x4080ffff) IIC_EEPROM mb_opb >> (0x40c00000-0x40c0ffff) Ethernet_MAC mb_opb >> (0x41200000-0x4120ffff) opb_intc_0 mb_opb >> (0x41400000-0x4140ffff) debug_module mb_opb >> (0x41800000-0x4180ffff) SysACE_CompactFlash mb_opb >> (0x41c00000-0x41c0ffff) opb_timer_1 mb_opb >> >> Connecting to cable (Parallel Port - LPT1). >> Checking cable driver. >> Driver windrvr6.sys version = 7.0.0.0.No resources. >> LPT base address = 0378h. >> ECP base address = 0778h. >> Cable connection failed. >> Connecting to cable (Parallel Port - LPT1). >> Checking cable driver. >> Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h. >> ECP base address = 0778h. >> Cable connection failed. >> Connecting to cable (Parallel Port - LPT2). >> Checking cable driver. >> Driver windrvr6.sys version = 7.0.0.0.Cable connection failed. >> Connecting to cable (Parallel Port - LPT2). >> Checking cable driver. >> Driver windrvr6.sys version = 7.0.0.0.Cable connection failed. >> Connecting to cable (Usb Port - USB22). >> Checking cable driver. >> Driver xusbdfwu.sys version: 1021 (1021). >> Driver windrvr6.sys version = 7.0.0.0.Calling setinterface num=0, >> alternate=0. >> DeviceAttach: received and accepted attach for: >> vendor id 0x3fd, product id 0x8, device handle 0x16726b4 >> Cable PID = 0008. >> Max current requested during enumeration is 280 mA. >> Cable Type = 3, Revision = 0. >> Setting cable speed to 6 MHz. >> Cable connection established. >> Firmware version = 1021. >> CPLD file version = 0012h. >> CPLD version = 0012h. >> >> JTAG chain configuration >> -------------------------------------------------- >> Device ID Code IR Length Part Name >> 1 0a001093 8 System_ACE >> 2 05059093 16 XCF32P >> 3 01e58093 10 XC4VFX12 >> 4 09608093 8 xc95144xl >> Assuming, Device No: 3 contains the MicroBlaze system >> Connected to the JTAG MicroProcessor Debug Module (MDM) >> No of processors = 1 >> >> MicroBlaze Processor 1 Configuration : >> ------------------------------------- >> Version............................5.00.a >> No of PC Breakpoints...............2 >> No of Read Addr/Data Watchpoints...0 >> No of Write Addr/Data Watchpoints..0 >> Instruction Cache Support..........on >> Instruction Cache Base Address.....0x24000000 >> Instruction Cache High Address.....0x27ffffff >> Data Cache Support.................on >> Data Cache Base Address............0x24000000 >> Data Cache High Address............0x27ffffff >> Exceptions Support................off >> FPU Support.......................off >> FSL DCache Support.................on >> FSL ICache Support.................on >> Hard Divider Support...............on >> Hard Multiplier Support............on >> Barrel Shifter Support.............on >> MSR clr/set Instruction Support....on >> Compare Instruction Support........on >> PVR Supported......................off >> JTAG MDM Connected to MicroBlaze 1 >> Connected to "mb" target. id = 0 >> Starting GDB server for "mb" target (id = 0) at TCP port no 1234 >> XMD% state >> Connected targets state >> >> Target ID State Target Type >> ---------------------------------------------------------- >> 0 Stopped MicroBlaze MDM-based (hw) Target >> XMD% mrd 0x24000000 100 >> 24000000: FFFFFDFF >> 24000004: FFFFFFFF >> 24000008: FFFFFFFF >> 2400000C: FFFFFEFF >> 24000010: FFDFFFFF >> 24000014: FFFFFFFF >> 24000018: FFFFFFFF >> 2400001C: FFFFFFFF >> 24000020: FFFFFFFF >> 24000024: FFFF7FFF >> 24000028: BFFFFBFF >> 2400002C: FFFFFFFF >> 24000030: FFFFF7FF >> 24000034: FFFFFFFF >> 24000038: FFFFFFFE >> 2400003C: FFFFFFFF >> 24000040: FFFFFDFF >> 24000044: FFFFFFF7 >> 24000048: FFFFFFFF >> 2400004C: FFFFFFFF >> 24000050: FFFF7FFF >> 24000054: FFFFFFFF >> 24000058: FFFFBFFF >> 2400005C: FFFFFFFF >> 24000060: FFFFFFFF >> 24000064: FFFFFFFF >> 24000068: FFFFFBFF >> 2400006C: FFFFFFFF >> 24000070: FFFFDDFF >> 24000074: FFFFF7FF >> 24000078: FFFFFFFF >> 2400007C: FFFFFFFF >> 24000080: FFFFFFFF >> 24000084: 7FFFFFFF >> 24000088: FFFFFFFF >> 2400008C: FFFFFFFF >> 24000090: FDFFFFFF >> 24000094: FFFFFFFF >> 24000098: FFFFFFFF >> 2400009C: FFFFFFFF >> 240000A0: FFFFFFFF >> 240000A4: FFFFFFFF >> 240000A8: FFFFFFFF >> 240000AC: FFFFFFFF >> 240000B0: FFFF7FFD >> 240000B4: FFFFFFFF >> 240000B8: BFFFFFFF >> 240000BC: BFFFFFFF >> 240000C0: FFFFFFFF >> 240000C4: FFFFF77F >> 240000C8: FFFFFBFF >> 240000CC: FFFFFFFF >> 240000D0: FFDFFFFF >> 240000D4: FFFFFFFF >> 240000D8: FFFEFFFF >> 240000DC: FFFFFFBF >> 240000E0: FFFFFFFF >> 240000E4: FFFFFFDF >> 240000E8: FFFFFBFF >> 240000EC: FBFFFFFF >> 240000F0: FFFFFFFF >> 240000F4: FFFFFFFF >> 240000F8: FFFFFFFF >> 240000FC: FFFFFFFF >> 24000100: FFFFFFFF >> 24000104: FFDFFFFF >> 24000108: FFEFFBFF >> 2400010C: FFFFFFFF >> 24000110: FFFFFFFF >> 24000114: F7FFFFFF >> 24000118: FFFFFFFF >> 2400011C: FFFFFFFF >> 24000120: FFFFFFFF >> 24000124: FFF7FFDF >> 24000128: FFFFFFFF >> 2400012C: FFFFFFFF >> 24000130: FFFFFFFF >> 24000134: FFFFFFFF >> 24000138: FFFFFBFF >> 2400013C: FFFFFFFF >> 24000140: FFFFDFFF >> 24000144: FFFFFFFF >> 24000148: BFFFFFFF >> 2400014C: FEFFFFFF >> 24000150: FFFFFFFF >> 24000154: FFFFFFFF >> 24000158: FFFFFFFF >> 2400015C: EFFFFFFF >> 24000160: FFFFFFFF >> 24000164: FFFFFFFF >> 24000168: FFFFBEFF >> 2400016C: FFFFFFFF >> 24000170: FFFFFDFF >> 24000174: FFFFFFFF >> 24000178: FFFFFFFF >> 2400017C: FFFFFFFF >> 24000180: FFFFFFFF >> 24000184: FFFFFDFF >> 24000188: FFFFFEFF >> 2400018C: FFFFFFFF >> >> XMD% mwr 0x24000000 1 >> XMD% mrd 0x24000000 1 >> 24000000: 00000001 >> >> XMD% dow -data image.bin 0x24000000 >> XMD% mrd 0x24000000 100 >> 24000000: 00000001 >> 24000004: FFFFFFFF >> 24000008: FFFFFFFF >> 2400000C: FFFFFEFF >> 24000010: FFDFFFFF >> 24000014: FFFFFFFF >> 24000018: FFFFFFFF >> 2400001C: FFFFFFFF >> 24000020: FFFFFFFF >> 24000024: FFFF7FFF >> 24000028: BFFFFBFF >> 2400002C: FFFFFFFF >> 24000030: FFFFF7FF >> 24000034: FFFFFFFF >> 24000038: FFFFFFFE >> 2400003C: FFFFFFFF >> 24000040: FFFFFDFF >> 24000044: FFFFFFF7 >> 24000048: FFFFFFFF >> 2400004C: FFFFFFFF >> 24000050: FFFF7FFF >> 24000054: FFFFFFFF >> 24000058: FFFFBFFF >> 2400005C: FFFFFFFF >> 24000060: FFFFFFFF >> 24000064: FFFFFFFF >> 24000068: FFFFFBFF >> 2400006C: FFFFFFFF >> 24000070: FFFFDDFF >> 24000074: FFFFF7FF >> 24000078: FFFFFFFF >> 2400007C: FFFFFFFF >> 24000080: FFFFFFFF >> 24000084: 7FFFFFFF >> 24000088: FFFFFFFF >> 2400008C: FFFFFFFF >> 24000090: FDFFFFFF >> 24000094: FFFFFFFF >> 24000098: FFFFFFFF >> 2400009C: FFFFFFFF >> 240000A0: FFFFFFFF >> 240000A4: FFFFFFFF >> 240000A8: FFFFFFFF >> 240000AC: FFFFFFFF >> 240000B0: FFFF7FFD >> 240000B4: FFFFFFFF >> 240000B8: BFFFFFFF >> 240000BC: BFFFFFFF >> 240000C0: FFFFFFFF >> 240000C4: FFFFF77F >> 240000C8: FFFFFBFF >> 240000CC: FFFFFFFF >> 240000D0: FFDFFFFF >> 240000D4: FFFFFFFF >> 240000D8: FFFEFFFF >> 240000DC: FFFFFFBF >> 240000E0: FFFFFFFF >> 240000E4: FFFFFFDF >> 240000E8: FFFFFBFF >> 240000EC: FBFFFFFF >> 240000F0: FFFFFFFF >> 240000F4: FFFFFFFF >> 240000F8: FFFFFFFF >> 240000FC: FFFFFFFF >> 24000100: FFFFFFFF >> 24000104: FFDFFFFF >> 24000108: FFEFFBFF >> 2400010C: FFFFFFFF >> 24000110: FFFFFFFF >> 24000114: F7FFFFFF >> 24000118: FFFFFFFF >> 2400011C: FFFFFFFF >> 24000120: FFFFFFFF >> 24000124: FFF7FFDF >> 24000128: FFFFFFFF >> 2400012C: FFFFFFFF >> 24000130: FFFFFFFF >> 24000134: FFFFFFFF >> 24000138: FFFFFBFF >> 2400013C: FFFFFFFF >> 24000140: FFFFDFFF >> 24000144: FFFFFFFF >> 24000148: BFFFFFFF >> 2400014C: FEFFFFFF >> 24000150: FFFFFFFF >> 24000154: FFFFFFFF >> 24000158: FFFFFFFF >> 2400015C: EFFFFFFF >> 24000160: FFFFFFFF >> 24000164: FFFFFFFF >> 24000168: FFFFBEFF >> 2400016C: FFFFFFFF >> 24000170: FFFFFDFF >> 24000174: FFFFFFFF >> 24000178: FFFFFFFF >> 2400017C: FFFFFFFF >> 24000180: FFFFFFFF >> 24000184: FFFFFDFF >> 24000188: FFFFFEFF >> 2400018C: FFFFFFFF >> >> XMD% >> >> --- >8 --- >> > >Article: 111758
Hello, I am using Cadence NC-Sim to simulate my design. The compilation is OK. After the elaborator process I got the message : (...\NCSIM\FDPE.v,35|22): Hierarchical name component lookup failed at 'glbl'. In the primitive FDPE.v, it refers to the following line : ... tri0 GSR = glbl.GSR; ... How should I define glbl.GSR ? Regards, JulienArticle: 111759
> - State a). Original design > - State b). Originial design + output pin added + compiled + output pin > removed + compiled This is not the expected behaviour of Quartus. Imagine how difficult our job would be if we could not reproduce outputs for a given set of inputs... Quartus is deterministic. The same input source and project settings run on the same version of Quartus on the same OS, you should get the same answer. Try diff'ing the output files of Quartus for your two cases. At what point in the compile do the report and log files differ? That may give a clue as to what is causing this difference in observed behaviuor. Are you absolutely positive that (b) gives the same inputs as (a)? For example, if you nuke your db/ directory in (a), and do the same in (b), do you then get the same results? If you can show that this is non-deterministic, please email me so that we can arrange to get your test case. We do occasionally find non-determinism in the software due to safe but bad programming practices -- for example, hashing on non-deterministic data. But we run determinism tests on the software, so these are usually flagged in-house before the software ever reaches our users. Regards, Paul Leventis Altera Corp.Article: 111760
If you use ISE gui, you can add different ucf to different project. If you use command line, you can use "-uc" option to specify which ucf to use with ngdbuild. HTH, Jim http://home.comcast.net/~jimwu88/tools/ Brad Smallridge wrote: > Is there any way to switch from a ucf file for > an ML402 dev board to a ucf file for a ML403 > board without having to delete one file from > the project and copy the source from another > ucf file? Can it automatically know what ucf > file to use based on the FX12 or SX35 part? > > Brad Smallridge > aivision > dot > comArticle: 111761
Please check http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=5474 HTH, Jim http://home.comcast.net/~jimwu88/tools/ Julien Lochen wrote: > Hello, > > I am using Cadence NC-Sim to simulate my design. > > The compilation is OK. > > After the elaborator process I got the message : > (...\NCSIM\FDPE.v,35|22): Hierarchical name component lookup failed at > 'glbl'. > > In the primitive FDPE.v, it refers to the following line : > > ... > tri0 GSR = glbl.GSR; > ... > > How should I define glbl.GSR ? > > Regards, JulienArticle: 111762
Jialin wrote: > But I want to load data/program into the SRAM of that board, > do you know how can I do that? What I normally do is create a simple circuit that can read a hex file (either Intel format or Motorola S Record, but more often my own simplified format) from the serial port and then just use the "send text file" option in Hyperterminal on the PC. After that is finished I download the actual circuit to the board. Since this is SRAM the contents won't be lost while the FPGA is being programmed (in practice even DRAMs tend to keep their data long enough). I don't have such a circuit ready for the Spartan 3 starter kit, but I tried following the instructions in http://members.optushome.com.au/jekent/Spartan3/index.html worked just fine for me. Here you have a small monitor program in the block RAM which allows you to load stuff from the serial port, so the same design downloads to memory and then uses the content unlike what I suggested above. -- JecelArticle: 111763
Hi, is there anyone who have a clue on how a synthesizer will do the RTL for bidirectional bus inside your logic? As far as I know high impedence are not synthesizable in the internal logic, only on I/O. Is this correct for all the FPGA? Are there any schematic example on how these bidirectional busses are implemented? Thanks Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 111764
Paul Leventis wrote: > > - State a). Original design > > - State b). Originial design + output pin added + compiled + output pin > > removed + compiled > > This is not the expected behaviour of Quartus. Imagine how difficult > our job would be if we could not reproduce outputs for a given set of > inputs... > > Quartus is deterministic. The same input source and project settings > run on the same version of Quartus on the same OS, you should get the > same answer. > > Try diff'ing the output files of Quartus for your two cases. At what > point in the compile do the report and log files differ? That may give > a clue as to what is causing this difference in observed behaviuor. > Are you absolutely positive that (b) gives the same inputs as (a)? For > example, if you nuke your db/ directory in (a), and do the same in (b), > do you then get the same results? > > If you can show that this is non-deterministic, please email me so that > we can arrange to get your test case. We do occasionally find > non-determinism in the software due to safe but bad programming > practices -- for example, hashing on non-deterministic data. But we > run determinism tests on the software, so these are usually flagged > in-house before the software ever reaches our users. > > Regards, > > Paul Leventis > Altera Corp. Thanks for your response. By this time I have fixed the problem that caused the original circuit not to work as supposed. There was some critical timing issue that caused a shift register a) not to load b) to load only certain flip-flops or c) to load correctly depending on how fast the "load" pin was deasserted after the clock edge. My fault. Coming to the "non-deterministic" question, I am pretty sure that Quartus does a correct job. To find an explanation, I wonder if it is possible that the same schematic ,i.e. screen drawing, may be given different internal representations. I explain with an example: Many years ago I wrote a circuit simulator where I assigned each circuit node a number which was internally generated. If the user addded and removed stuff, the internal node numbers changed but the screen appearance was the same. In this case, this could not affect the circuit response. However, in this case I can imagine that the fitter tool, if all settings are the same, starts to place things perhaps by ascending order of an internal variable which may be different even if the screen "appearence" is the same -perhaps due to repeated adding or deleting?? Could it be that, if there are no restrictions acting, the decision on where to start placing may be based on some internal ordering, which could cause those minor timing differences -which in the reported case caused big behavior diferences due do a bad design? (Sorry that I can't send you the original state, because, as said, it worked after editing and this was done on the same project) Pere Pal=E0Article: 111765
Al wrote: > Hi, > is there anyone who have a clue on how a synthesizer will do the RTL for > bidirectional bus inside your logic? The synthesizer infers a tri-buff. Here's a code example: http://home.comcast.net/~mike_treseler/oe_demo.vhdArticle: 111766
You can use the OBUFDS for differential output. You should be able to the same with I/O constraints. You will need to use an bank voltage of 2.5V for output LVDS operation. There will be a skew between output pairings. If they are clocked outputs with flip-flops in the I/O then that is related to differences in internal clock routing delays.If you are just doing a route through from a clock source there will be variance due to differences in internal routing delays. There will also be small variance due to bond out wires/routing. Jitter will depend on your clock sources. If you use a DCM there will be jitter related to that. Your origional clock source will have jitter too and that can be impressed on outputs. John Adair Enterpoint Ltd. Julien Lochen wrote: > Hello, > > I work as Design Engineer at Bull SAS in France (Server Design and > Development). > > I saw a webcase on the web in which someone try to provide some > guidance concerning LVDS signals. I am not sure to have understood all > your answers, so please let me ask the following question : > > I am currently working on a design based on the spartan XC3S1000. > > Can it be used to drive LVDS clocks ? (LVDS clock's frenquency is 100 > Mhz). > > If yes, what output buffers should we use ? (Is there an "OBUFGDS" in > the XC3S1000 ?). > > What will be the maximum jitter between these 100Mhz-LVDS clocks ? > > Thanks a lot for your answers, JulienArticle: 111767
Mike Treseler wrote:
> The synthesizer infers a tri-buff.
Sorry, I didn't read the whole question.
Synthesis will convert tri-buff inferences to muxes.
-- Mike Treseler
Article: 111768Davy wrote: > > Do you mean both ASIC and FPGA have methodology forbid gated clocks (I > know that FPGA forbid gated clock and use clock enabled D-FF). Thanks! I am not talking about the rules enforced by particular tools. I am talking about general good digital design practices, independent of the implementation technology. Gated clocks create bugs in designs, due to timing problems from extra clock skew, and the potential for glitches on the clocks being created by the gating logic. When I was an undergraduate student 20 years ago, we were taught never to gate a clock. There are some design methodologies that do it, but I expect that the successful ones have very strict rules about when and how to do it. That is why you found a paper that was written about a way to do it correctly. If you don't have the skill and discipline to do it exactly right, you should avoid it entirely.Article: 111769
Ah. Two schematics that look the same could very well turn into different input as far as Quartus is concerned. This is just like you choosing to reorder some expressions in your HDL; I can't say for sure without trying it, but I can envision this turning into different node numbers / names in the internal representation and causing different results. I'm glad that you were able to resolve your issue. Good luck with your design! Paul Leventis Altera Corp.Article: 111770
I'm working on a XUP-V2Pro project which needs both the VDEC-1 video capture card and a 256-MB memory module. The Base System Builder produced a UCF file that have these lines: Net fpga_0_DDR_CLK_FB LOC=C16; Net fpga_0_DDR_CLK_FB IOSTANDARD = SSTL2_II; Net fpga_0_DDR_CLK_FB_OUT LOC=G23; Net fpga_0_DDR_CLK_FB_OUT IOSTANDARD = SSTL2_II; Digilent's Video Capture sample has this: NET "LLC_CLOCK" LOC = "B16" | IOSTANDARD = LVCMOS25 ; NET "LLC_CLOCK" PERIOD = 25 ns; All three of these pins are in bank 0; this causes the tools to produce this error: ERROR:Place:311 - The IOB LLC_CLOCK is locked to site PAD55 in bank 0. This violates the SelectIO banking rules. Other incompatible IOBs may be locked to the same bank, or this IOB may be illegally locked to a Vref site. The design builds if I change LLC_CLOCK to SSTL2_II, but I don't know if this will work reliably (I'm not familiar with SSTL2_II). Did whomever designed the XUP really place incompatible IO standards on bank 0? Is there a good way around this error? ToddArticle: 111771
Correction: it did *not* build when I changed LLC_CLOCK to SSTL2_II; the error message was burried (the same message as before) and I missed it. I tried removing LLC_CLOCK's LOC constraint and leaving it LVCMOS25 and this did build. Of course this option is not viable -- LLC_CLOCK is tied to B16 on the PCBs. I looked up the footprint for the XC2VP30 FF896 (Used by the XUP) and noticed that B16 (IO_L74P_0/GCLK6S) and C16 (IO_L74N_0/GCLK7P) form a pair. Could this be the cause of the problem? Todd Todd Fleming wrote: > I'm working on a XUP-V2Pro project which needs both the VDEC-1 video > capture card and a 256-MB memory module. The Base System Builder > produced a UCF file that have these lines: > > Net fpga_0_DDR_CLK_FB LOC=C16; > Net fpga_0_DDR_CLK_FB IOSTANDARD = SSTL2_II; > Net fpga_0_DDR_CLK_FB_OUT LOC=G23; > Net fpga_0_DDR_CLK_FB_OUT IOSTANDARD = SSTL2_II; > > Digilent's Video Capture sample has this: > > NET "LLC_CLOCK" LOC = "B16" | IOSTANDARD = LVCMOS25 ; > NET "LLC_CLOCK" PERIOD = 25 ns; > > All three of these pins are in bank 0; this causes the tools to produce > this error: > > ERROR:Place:311 - The IOB LLC_CLOCK is locked to site PAD55 in bank 0. > This violates the SelectIO banking rules. > Other incompatible IOBs may be locked to the same bank, or this IOB > may be illegally locked to a Vref site. > > The design builds if I change LLC_CLOCK to SSTL2_II, but I don't know > if this will work reliably (I'm not familiar with SSTL2_II). Did > whomever designed the XUP really place incompatible IO standards on > bank 0? Is there a good way around this error? > > ToddArticle: 111772
Here's another clue. I checked the .pad file after I built (without a loc constraint on LLC_CLOCK) and noticed that B16 is occupied by signal "IO_x_x_x_x"; there are similarly-named signals throughout the .pad file, each with a different number of "_x"'s. None of my signals have names that are anything like this; where are these coming from? Todd Todd Fleming wrote: > Correction: it did *not* build when I changed LLC_CLOCK to SSTL2_II; > the error message was burried (the same message as before) and I missed > it. I tried removing LLC_CLOCK's LOC constraint and leaving it > LVCMOS25 and this did build. Of course this option is not viable -- > LLC_CLOCK is tied to B16 on the PCBs. > > I looked up the footprint for the XC2VP30 FF896 (Used by the XUP) and > noticed that B16 (IO_L74P_0/GCLK6S) and C16 (IO_L74N_0/GCLK7P) form a > pair. Could this be the cause of the problem? > > ToddArticle: 111773
Since SSTL2 is a 2.5V standard as is LVCMOS25, you possibly have a different I/O in that bank. Take a look at the pad report that shows which I/O standards are getting assigned to which banks. You'll probably find a third I/O standard in that bunch. Either that or there's a problem with the VREF inputs (which should also be noted in the pad report). "Todd Fleming" <tbfleming@gmail.com> wrote in message news:1163104397.297669.297210@h48g2000cwc.googlegroups.com... > I'm working on a XUP-V2Pro project which needs both the VDEC-1 video > capture card and a 256-MB memory module. The Base System Builder > produced a UCF file that have these lines: > > Net fpga_0_DDR_CLK_FB LOC=C16; > Net fpga_0_DDR_CLK_FB IOSTANDARD = SSTL2_II; > Net fpga_0_DDR_CLK_FB_OUT LOC=G23; > Net fpga_0_DDR_CLK_FB_OUT IOSTANDARD = SSTL2_II; > > Digilent's Video Capture sample has this: > > NET "LLC_CLOCK" LOC = "B16" | IOSTANDARD = LVCMOS25 ; > NET "LLC_CLOCK" PERIOD = 25 ns; > > All three of these pins are in bank 0; this causes the tools to produce > this error: > > ERROR:Place:311 - The IOB LLC_CLOCK is locked to site PAD55 in bank 0. > This violates the SelectIO banking rules. > Other incompatible IOBs may be locked to the same bank, or this IOB > may be illegally locked to a Vref site. > > The design builds if I change LLC_CLOCK to SSTL2_II, but I don't know > if this will work reliably (I'm not familiar with SSTL2_II). Did > whomever designed the XUP really place incompatible IO standards on > bank 0? Is there a good way around this error? > > Todd >Article: 111774
I came across the posting for the Stratix III the other day on their website. Short of putting engineering samples in everybody hands, you'd think they would want to coordinate the release of the new version of Quartus II with the announcement for the new devices so that engineers can see how their desings fair in the new software and devices. I only had a few minutes to look at the website but the new devices look like they have made them more granular and have doubled the frequency of their devices. I am a Quartus II user and my sales rep, Linda, has always done a good job of getting me a copy of the software. So, I have one morew thing to look forward to in December. Derek Tommy Thorn wrote: > Relevant to several recent threads, Altera just announced their Stratix > III and with it Quartus 6.1 of which the first bullet item is: > > "Multiprocessor support: Allowing parallel processing during > compilation for computers with multiple processors results in a > reduction in compile times. Quartus II software offers the first > multiprocessor support from an FPGA vendor to take advantage of the new > multiple-core processors." > > The actual software is available *now* (according to the press > release). Trying to get it reveals that *now* is really December 4th > :-) > > I look forward to see how it scales with multiple cores. > > Tommy
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