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
In my application, I was trying to switch from using an opb_timer to a fit_timer to save on resources, but seem to be having some trouble correctly connecting the interrupt. I wire the interrupt from the fit_timer to my microblaze interrupt port just fine, but I do not get an entry for it in my Software Platform Settings list like I normally do. I noticed that the fit_timer is not automatically associated with a driver like the opb_timer is, so I made an attempt to modify the .mdd for the opb_timer driver to match my fit_timer and then hand edit the .mss file to reflect it, but I still don't see the entry on the Interrupt Handlers page and my device does not work. I'm sure that I'm missing something obvious, but I don't see it. Any ideas?Article: 119626
Hi, Don't connect the fit_timer or ordinary timer to MicroBlaze, connect them to the interrupt controller instead. Göran "Carter De Leo" <cdeleo@calpoly.edu> wrote in message news:eea6f25.-1@webx.sUN8CHnE... > In my application, I was trying to switch from using an opb_timer to a > fit_timer to save on resources, but seem to be having some trouble > correctly connecting the interrupt. I wire the interrupt from the > fit_timer to my microblaze interrupt port just fine, but I do not get an > entry for it in my Software Platform Settings list like I normally do. I > noticed that the fit_timer is not automatically associated with a driver > like the opb_timer is, so I made an attempt to modify the .mdd for the > opb_timer driver to match my fit_timer and then hand edit the .mss file to > reflect it, but I still don't see the entry on the Interrupt Handlers page > and my device does not work. I'm sure that I'm missing something obvious, > but I don't see it. Any ideas?Article: 119627
Hi to all i would to use SATA OOB detection with Virtex5 GTPs. Iam using the ML505 development board with the two SATA connectors, connected with the crossovercable. Now to the problem: if i sends an OOB signal from one GTP to another by make the TXCOMSTART high, the anathor GTP receives something and takes the RXELECIDLE high (it means an OOB signal was detected), but the RXSTATUS bus remains constant. So the logic cant identificate the OOB-signal. Another problem is, if i connect a SATA-HDD to the board the RXELECIDLE goes high. Is the OOB detection at Virtex5 dont working? Knows somebody this problem?Article: 119628
I have a question: I think that gmake is not installed in my operating system (solaris) >whereis gmake gmake: > whereas make is intalled >whereis make make: /usr/bin/make /usr/X11R6/bin/make /usr/bin/X11/make /usr/share/man/man1/make.1.gz > What file and how should I change in order to use make with LIBGEN ? Thank you for your consideration. Best regards Fernando Ortiz CuestaArticle: 119629
On 24 Mai, 09:38, a...@web.de wrote: > Hi to all i would to use SATA OOB detection with Virtex5 GTPs. > Iam using the ML505 development board with the two SATA connectors, > connected with the crossovercable. > Now to the problem: if i sends an OOB signal from one GTP to another > by make the TXCOMSTART high, > the anathor GTP receives something and takes the RXELECIDLE high (it > means an OOB signal was detected), but the RXSTATUS bus remains > constant. > So the logic cant identificate the OOB-signal. Another problem is, if > i connect a SATA-HDD to the board the RXELECIDLE goes high. > Is the OOB detection at Virtex5 dont working? > Knows somebody this problem? well SATA OOB is timed sequence of IDLE and not-IDLE pulses, so if you connect the RXELECIDLE to SATA OOB detector IP then you all should be fine if you connect SATA HDD, then you should expect not much, until you perfomr the OOB sequence to establish the link AnttiArticle: 119630
Hi, I am at my initial stage of design with a Microblaze which is connected to two peripherals through FSLs. The connection is like Microblaze -> peripheral_1 -> peripheral_2 -> back to Microblaze. Master of first FSL connected to Microblaze and slave end to Peripheral_1. Master of Second FSL connected to Peripheral_1 and Slave end to Peripheral_2. Master of Third FSL connected to Peripheral_2 and Slave end to Microblaze. After generating the Netlist and Bitstream, when I am trying to Generate Libraries and BSP I am getting following errors: ********************************************* Creating software libraries... ********************************************* libgen -mhs system.mhs -p xc4vlx25ff668-10 system.mss libgen Xilinx EDK 9.1.02 Build EDK_J_SP2.4 Copyright (c) 1995-2007 Xilinx, Inc. All rights reserved. Command Line: libgen -mhs system.mhs -p xc4vlx25ff668-10 system.mss Output Directory (-od) : E:\microblaze_shant\projects\VideoCompr \ver_5\ Part (-p) : virtex4 Software Specification file : system.mss Sourcing tcl file C:/EDK/hw/XilinxProcessorIPLib/pcores/microblaze_v6_00_b/data/ microblaze_v2_1_0. tcl ... Sourcing tcl file C:/EDK/hw/XilinxProcessorIPLib/pcores/opb_mdm_v2_00_a/data/ opb_mdm_v2_1_0.tcl ... Sourcing tcl file C:/EDK/hw/XilinxProcessorIPLib/pcores/lmb_v10_v1_00_a/data/ lmb_v10_v2_1_0.tcl ... Sourcing tcl file C:/EDK/hw/XilinxProcessorIPLib/pcores/lmb_bram_if_cntlr_v2_00_a/data/ lmb_bram_if _cntlr_v2_1_0.tcl ... Sourcing tcl file C:/EDK/hw/XilinxProcessorIPLib/pcores/dcm_module_v1_00_c/data/ dcm_module_v2_1_0. tcl ... Sourcing tcl file C:/EDK/hw/XilinxProcessorIPLib/pcores/fsl_v20_v2_10_a/data/ fsl_v20_v2_1_0.tcl ... Overriding IP level properties ... INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 66 - microblaze_0 (microblaze) tool is overriding PARAMETER C_FAMILY value to virtex4 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 67 - microblaze_0 (microblaze) tool is overriding PARAMETER C_INSTANCE value to microblaze_0 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 102 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_ADDR_TAG_BITS value to 0 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 110 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_DCACHE_ADDR_TAG value to 0 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_mdm_v2_00_a\data \opb_mdm_v2_1_0.mpd line 41 - debug_module (opb_mdm) tool is overriding PARAMETER C_FAMILY value to virtex4 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\bram_block_v1_00_a\data \bram_block_v2_1 _0.mpd line 41 - lmb_bram (bram_block) tool is overriding PARAMETER C_FAMILY value to virtex4 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\dcm_module_v1_00_c\data \dcm_module_v2_1 _0.mpd line 59 - dcm_0 (dcm_module) tool is overriding PARAMETER C_FAMILY value to virtex4 Performing IP level DRCs on properties... Running DRC Tcl procedures for OPTION IPLEVEL_DRC_PROC... Address Map for Processor microblaze_0 (0000000000-0x00003fff) dlmb_cntlr dlmb (0000000000-0x00003fff) ilmb_cntlr ilmb (0x40600000-0x4060ffff) RS232_Uart mb_opb (0x41400000-0x4140ffff) debug_module mb_opb Check platform address map ... Overriding system level properties ... INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 69 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_D_OPB value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 70 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_D_LMB value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 71 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_I_OPB value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 72 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_I_LMB value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 92 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_INTERRUPT_IS_EDGE value to 0 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\microblaze_v6_00_b\data \microblaze_v2_1 _0.mpd line 93 - microblaze_0 (microblaze) tcl is overriding PARAMETER C_EDGE_IS_POSITIVE value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_v20_v1_10_c\data \opb_v20_v2_1_0.mpd line 36 - mb_opb (opb_v20) tool is overriding PARAMETER C_OPB_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_v20_v1_10_c\data \opb_v20_v2_1_0.mpd line 37 - mb_opb (opb_v20) tool is overriding PARAMETER C_OPB_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_v20_v1_10_c\data \opb_v20_v2_1_0.mpd line 38 - mb_opb (opb_v20) tool is overriding PARAMETER C_NUM_MASTERS value to 2 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_v20_v1_10_c\data \opb_v20_v2_1_0.mpd line 39 - mb_opb (opb_v20) tool is overriding PARAMETER C_NUM_SLAVES value to 2 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_v10_v1_00_a\data \lmb_v10_v2_1_0.mpd line 38 - ilmb (lmb_v10) tool is overriding PARAMETER C_LMB_NUM_SLAVES value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_v10_v1_00_a\data \lmb_v10_v2_1_0.mpd line 39 - ilmb (lmb_v10) tool is overriding PARAMETER C_LMB_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_v10_v1_00_a\data \lmb_v10_v2_1_0.mpd line 40 - ilmb (lmb_v10) tool is overriding PARAMETER C_LMB_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_v10_v1_00_a\data \lmb_v10_v2_1_0.mpd line 38 - dlmb (lmb_v10) tool is overriding PARAMETER C_LMB_NUM_SLAVES value to 1 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_v10_v1_00_a\data \lmb_v10_v2_1_0.mpd line 39 - dlmb (lmb_v10) tool is overriding PARAMETER C_LMB_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_v10_v1_00_a\data \lmb_v10_v2_1_0.mpd line 40 - dlmb (lmb_v10) tool is overriding PARAMETER C_LMB_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_bram_if_cntlr_v2_00_a\data \lmb_bram _if_cntlr_v2_1_0.mpd line 44 - dlmb_cntlr (lmb_bram_if_cntlr) tool is overriding PARAMETER C_MASK value to 0x00400000 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_bram_if_cntlr_v2_00_a\data \lmb_bram _if_cntlr_v2_1_0.mpd line 45 - dlmb_cntlr (lmb_bram_if_cntlr) tool is overriding PARAMETER C_LMB_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_bram_if_cntlr_v2_00_a\data \lmb_bram _if_cntlr_v2_1_0.mpd line 46 - dlmb_cntlr (lmb_bram_if_cntlr) tool is overriding PARAMETER C_LMB_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_bram_if_cntlr_v2_00_a\data \lmb_bram _if_cntlr_v2_1_0.mpd line 44 - ilmb_cntlr (lmb_bram_if_cntlr) tool is overriding PARAMETER C_MASK value to 0x00400000 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_bram_if_cntlr_v2_00_a\data \lmb_bram _if_cntlr_v2_1_0.mpd line 45 - ilmb_cntlr (lmb_bram_if_cntlr) tool is overriding PARAMETER C_LMB_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\lmb_bram_if_cntlr_v2_00_a\data \lmb_bram _if_cntlr_v2_1_0.mpd line 46 - ilmb_cntlr (lmb_bram_if_cntlr) tool is overriding PARAMETER C_LMB_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\bram_block_v1_00_a\data \bram_block_v2_1 _0.mpd line 37 - lmb_bram (bram_block) tool is overriding PARAMETER C_MEMSIZE value to 0x4000 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\bram_block_v1_00_a\data \bram_block_v2_1 _0.mpd line 38 - lmb_bram (bram_block) tool is overriding PARAMETER C_PORT_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\bram_block_v1_00_a\data \bram_block_v2_1 _0.mpd line 39 - lmb_bram (bram_block) tool is overriding PARAMETER C_PORT_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\bram_block_v1_00_a\data \bram_block_v2_1 _0.mpd line 40 - lmb_bram (bram_block) tool is overriding PARAMETER C_NUM_WE value to 4 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_uartlite_v1_00_b\data \opb_uartlite_ v2_1_0.mpd line 37 - RS232_Uart (opb_uartlite) tool is overriding PARAMETER C_OPB_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_uartlite_v1_00_b\data \opb_uartlite_ v2_1_0.mpd line 38 - RS232_Uart (opb_uartlite) tool is overriding PARAMETER C_OPB_AWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_10_a\data \fsl_v20_v2_1_0.mpd line 40 - fsl_v20_0 (fsl_v20) tool is overriding PARAMETER C_FSL_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_10_a\data \fsl_v20_v2_1_0.mpd line 40 - fsl_v20_1 (fsl_v20) tool is overriding PARAMETER C_FSL_DWIDTH value to 32 INFO:MDT - C:\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_10_a\data \fsl_v20_v2_1_0.mpd line 40 - fsl_v20_2 (fsl_v20) tool is overriding PARAMETER C_FSL_DWIDTH value to 32 Running system level Update ... Running UPDATE Tcl procedures for OPTION SYSLEVEL_UPDATE_PROC... Performing System level DRCs on properties... Running DRC Tcl procedures for OPTION SYSLEVEL_DRC_PROC... Check platform configuration ... IPNAME:opb_v20 INSTANCE:mb_opb - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 46 - 2 master(s) : 2 slave(s) IPNAME:lmb_v10 INSTANCE:ilmb - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 71 - 1 master(s) : 1 slave(s) IPNAME:lmb_v10 INSTANCE:dlmb - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 79 - 1 master(s) : 1 slave(s) IPNAME:fsl_v20 INSTANCE:fsl_v20_0 - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 149 - 1 master(s) : 1 slave(s) IPNAME:fsl_v20 INSTANCE:fsl_v20_1 - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 157 - 1 master(s) : 1 slave(s) IPNAME:fsl_v20 INSTANCE:fsl_v20_2 - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 172 - 1 master(s) : 1 slave(s) Check port drivers... WARNING:MDT - INST:dcm_0 PORT:LOCKED CONNECTOR:dcm_0_lock - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 139 - floating connection! Performing Clock DRCs... INFO:MDT - List of peripherals addressable from processor instance microblaze_0 : - dlmb_cntlr - ilmb_cntlr - mb_opb WARNING:MDT - E:\microblaze_shant\projects\VideoCompr\ver_5\system.mhs line 46 - No Driver Found for instance mb_opb. To avoid seeing this warning, assign the appropriate driver or driver "generic 1.00.a " to instance mb_opb - debug_module - RS232_Uart - custom_ip_0 Building Directory Structure for microblaze_0 Generating platform libraries and device drivers ... Running CopyFiles ... Copying files for os standalone_v1_00_a from C:\EDK\sw\lib\bsp\standalone_v1_00_a\src\ to E:\microblaze_shant\projects\VideoCompr\ver_5\microblaze_0\libsrc \standalone_v1_ 00_a\ ... Copying files for driver uartlite_v1_02_a from C:\EDK\sw\XilinxProcessorIPLib\drivers\uartlite_v1_02_a\src\ to E:\microblaze_shant\projects\VideoCompr\ver_5\microblaze_0\libsrc \uartlite_v1_02 _a\ ... Copying files for driver custom_ip_v1_00_a from E:\microblaze_shant\projects\VideoCompr\ver_5\drivers\custom_ip_v1_00_a \src\ to E:\microblaze_shant\projects\VideoCompr\ver_5\microblaze_0\libsrc \custom_ip_v1_0 0_a\ ... Copying files for driver cpu_v1_01_a from C:\EDK\sw\XilinxProcessorIPLib\drivers\cpu_v1_01_a\src\ to E:\microblaze_shant\projects\VideoCompr\ver_5\microblaze_0\libsrc \cpu_v1_01_a\ ... Running DRCs for OSes, Drivers and Libraries ... Running generate for OS'es, Drivers and Libraries ... Generating Macros for FSL peripheral access ... Copying Library Files ... Running post_generate for OS'es, Drivers and Libraries ... Running make for Drivers and Libraries ... Configuring make for target include using: make -s include "COMPILER=mb-gcc" "ARCHIVER=mb-ar" "COMPILER_FLAGS=-mno-xl-soft-mul -mxl-pattern-compare -mcpu=v6.00.b - O2 -c" "EXTRA_COMPILER_FLAGS=-g" Configuring make for target libs using: make -s libs "COMPILER=mb-gcc" "ARCHIVER=mb-ar" "COMPILER_FLAGS=-mno-xl-soft-mul -mxl-pattern-compare -mcpu=v6.00.b - O2 -c" "EXTRA_COMPILER_FLAGS=-g" Compiling common Compiling Standalone BSP Compiling uartlite Compiling custom_ip_v1_00_a Compiling cpu /cygdrive/c/DOCUME~1/arvind/LOCALS~1/Temp/ccOil8Uy.s: Assembler messages: /cygdrive/c/DOCUME~1/arvind/LOCALS~1/Temp/ccOil8Uy.s:63: Error: register expected, but saw 'rfsl' /cygdrive/c/DOCUME~1/arvind/LOCALS~1/Temp/ccOil8Uy.s:63: Warning: ignoring operands: rfsl make[1]: *** [libs] Error 1 ERROR:MDT - make failed for target "libs" ERROR:MDT - Error while running "make" for processor microblaze_0... make: *** [microblaze_0/lib/libxil.a] Error 2 Done! Please throw some light on this problem of mine. Thanks and Regards, Shant ChandrakarArticle: 119631
I've found a 6502 core at http://www.sprow.co.uk/fpgas/free6502.htm , which is based on a version from free-ip.com, which looks like it turned into an advertising site, but I've found the original page at http://web.archive.org/web/20040603222048/www.free-ip.com/6502/index.html Under "Legal Stuff" it says "Currently, there are no known patents or copyrights that cover this implementation of the 6502 CPU.". But I wonder if MOS Technology or the successor companies has some copyrights for the 6502 architecture and if it is allowed to use it, without licence fees, in own designs. What are the general licensing issues for CPU cores? Is it possible to require licence fees for a CPU architecture or only for a CPU core, e.g. for a EDIF netlist? Can I create and use a cleanroom implemenation of a CPU architecture without legal problems? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119632
Hi I am doing a Spartan3 to Spartan 3 interconnect trough a ribbon (flat) cable with a characteristic impedance of 173R balanced (103R unbalanced). I have tried xilinx webcase to answer on the termination requirements of LVDS for spartan 3 withhout much luck. I got 2 different answers. My questions are: 1) Can I use a ribbon cable with 173R balanced characteristic impedance? I have read that it should be 100R. The transmission is rather short, 300mm and relative slow in lvds terms. I would rather not switch the cable since it have other good properities that I rely on. 2) With the above cable should the receiver end termination still be 100R 3) With the above cable is a source resistor network necessary to match the impedance on the transmitter side and lower reflections? This is the point where xilinx tend to confuse itself in its datasheets for spartan 3. My dirty solution with adding 150R series resisor tend to give nicer signals. Hope someone could help me on this. Thanks in advanceArticle: 119633
On May 24, 10:12 am, Frank Buss <f...@frank-buss.de> wrote: > But I wonder if MOS Technology or the successor companies has some > copyrights for the 6502 architecture No, there is no copyright on CPU architectures. (Speaking of the US and Germany) Also, the architecture of the free-ip 6502 is radically different from the architecture of the original 6502, so even if there was such a copyright the 6502 would likely be not infringing. Only the ISA is identically, but there also is no copyright on ISAs. There can be patents on architectures and on implementation techniques or features, without which a certain ISA might be next to impossible to implement (e.g. ARM has a patent on the barrelshifter/ALU combination) But the original 6502 is to old to have still open patent issues. Copyright protects only the actual implementation: The HDL, netlists, bitstreams, layouts, etc. > What are the general licensing issues for CPU cores? Is it possible to > require licence fees for a CPU architecture or only for a CPU core, e.g. > for a EDIF netlist? Can I create and use a cleanroom implemenation of a CPU > architecture without legal problems? You can reimplement any ISA, but it might happen that the architecture that you create violates some patent. BTW: This could be a patent that was created for a different architecture. I can imagine a 6502 implemenation that violates ARMs ALU patents, etc. Kolja SulimmaArticle: 119634
On 24 Mai, 10:03, Antti <Antti.Luk...@googlemail.com> wrote: > On 24 Mai, 09:38, a...@web.de wrote: > > > Hi to all i would to use SATA OOB detection with Virtex5 GTPs. > > Iam using the ML505 development board with the two SATA connectors, > > connected with the crossovercable. > > Now to the problem: if i sends an OOB signal from one GTP to another > > by make the TXCOMSTART high, > > the anathor GTP receives something and takes the RXELECIDLE high (it > > means an OOB signal was detected), but the RXSTATUS bus remains > > constant. > > So the logic cant identificate the OOB-signal. Another problem is, if > > i connect a SATA-HDD to the board the RXELECIDLE goes high. > > Is the OOB detection at Virtex5 dont working? > > Knows somebody this problem? > > well SATA OOB is timed sequence of IDLE and not-IDLE pulses, > so if you connect the RXELECIDLE to SATA OOB detector IP then you all > should be fine > if you connect SATA HDD, then you should expect not much, until you > perfomr the OOB > sequence to establish the link > > Antti Thanks for fast answer. that you say is correct but the OOB detector at the GTPs must deliver with the RXELECIDLE the type (COMINIT/ COMRESET/COMWAKE) of the OBB signal by changing the RXSTATUS port, by me its dont doing. And after connecting SATA HDD i have sending an COMRESET. Must i make something befor sending an OOB signal? Thanks alkoArticle: 119635
Antti wrote: > http://www.heise.de/mobil/artikel/88916/2 > http://www.heise.de/bilder/88916/2/1 > > pretty interesting - so funny that makes you wanna a child again ;) > ok, the price is not 100 but 150, guess the manufacturer did not meed > the 100 USD goal Interesting - but the Altera, only in the prototypes, I'd guess.... good overall idea tho. -jgArticle: 119636
and subin i didnt observed the last question...... what should be the real approch to write in HDL to get most optimised result. How can one suggest a general method or guideline for coding.... i think we can classify it as two separate class.... 1) general functionalities.... like addition,multiplication,muxing etc... i think here we need to code them as direct as u done in the first code.... all the synthesizers i hope will have algos to deal with that... so no ponit in creating something like 2nd or 3rd coding style.... tht looks nt good in the HDL itself.... 2) The other things are unconventional functionalities... like what we implemented in the source formatin switching logic.... we know what to do but no machine can translate direct to the optimized HW... so what we do we also think abt it and find a way to implement it and code it that way..... I think when we are coding somrthing we need to differentiate between these two class...Article: 119637
Hey, the basic ida looks good, but it's not very adaptable... I was just wondering whether you'd taken a look at http://direct.xilinx.com/bvdocs/appnotes/xapp029.pdf from this i made a generic converter, which takes two generic integers to define its length in terms of SB and BCD outputs. It's a nice little project following from your starting point, you might recognise the name of one of the authors from this group. Anyways - good luck! Ben "NA" <madid87-MAKNI-@yahoo.com> wrote in message news:op.tsthmdl03ik8el@soba... > On Thu, 24 May 2007 02:38:49 +0200, Kryten > <kryten_droid_obfusticator@ntlworld.com> wrote: >> Please do your own homework, thank you. > > This is not a homework and I NEVER asked "you" to write this for me. All I > asked is what is wrong like people ask in 90% other posts. > So you're reply is very rude, but you already know that. > > Anyway I found my problem. That piece of code was in a process sensitive > to clock (50MHz) and it would execute many times instead of one. If you > sll something "many" times you get zeros.Article: 119638
On 24 Mai, 10:32, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > >http://www.heise.de/mobil/artikel/88916/2 > >http://www.heise.de/bilder/88916/2/1 > > > pretty interesting - so funny that makes you wanna a child again ;) > > ok, the price is not 100 but 150, guess the manufacturer did not meed > > the 100 USD goal > > Interesting - but the Altera, only in the prototypes, I'd guess.... > > good overall idea tho. > > -jg Hi Jim, you maybe right, the OLPC minimum order quantity is 3 MILLION pieces, eg minimum order value of round 450 Mio USD, so I guess it does pay off to go ASIC at those volumes ;) I wonder a bit that the 100 USD target price goal have not met - as I heard there is serious project to develop a mobile phone with sub 10 USD manufacturing costs ! so if a mobile phone manufacturing cost can be pushed below 10 USD, then it is surprising that a laptop cant be pushed below 100 AnttiArticle: 119639
Frank Buss wrote: > I've found a 6502 core at http://www.sprow.co.uk/fpgas/free6502.htm , which > is based on a version from free-ip.com, which looks like it turned into an > advertising site, but I've found the original page at > > http://web.archive.org/web/20040603222048/www.free-ip.com/6502/index.html > > Under "Legal Stuff" it says "Currently, there are no known patents or > copyrights that cover this implementation of the 6502 CPU.". > > But I wonder if MOS Technology or the successor companies has some > copyrights for the 6502 architecture and if it is allowed to use it, > without licence fees, in own designs. > > What are the general licensing issues for CPU cores? Is it possible to > require licence fees for a CPU architecture or only for a CPU core, e.g. > for a EDIF netlist? Can I create and use a cleanroom implemenation of a CPU > architecture without legal problems? It also depends on what you intend to do with it. Companies lawyers will protect their patch - IIRC Atmel sued a phone company, that did what sounded like 'license creepage' of their AVR core : ie started designs using the AVR, and then did an ASIC with the same core. Look up the details. If your target is FPGA, then only ARM would be likely to go after you. (as they have small revenue streams via Actel FPGA). What sort of core are you looking at doing ? Why not look at the Mico8 and Mico32 from lattice, and contribute to that. That is fully opensource, and legal problem free. You could do a MicoFB, with your pet features... ? -jgArticle: 119640
NA wrote: > Anyway I found my problem. That piece of code was in a process sensitive > to clock (50MHz) and it would execute many times instead of one. If you > sll something "many" times you get zeros. This can't be the problem of the code you've posted, because "temp" is redefined every time and the rest of the steps are executed serially, because that's the way "variable" works, so you'll have the right "temp" value at the end. The problem with your code is the "unit := digit" line at the end, because "digit" is 0 at the first loop iteration and then "unit" becomes 0, too. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119641
On 24 Mai, 11:00, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Frank Buss wrote: > > I've found a 6502 core athttp://www.sprow.co.uk/fpgas/free6502.htm, which > > is based on a version from free-ip.com, which looks like it turned into an > > advertising site, but I've found the original page at > > >http://web.archive.org/web/20040603222048/www.free-ip.com/6502/index.... > > > Under "Legal Stuff" it says "Currently, there are no known patents or > > copyrights that cover this implementation of the 6502 CPU.". > > > But I wonder if MOS Technology or the successor companies has some > > copyrights for the 6502 architecture and if it is allowed to use it, > > without licence fees, in own designs. > > > What are the general licensing issues for CPU cores? Is it possible to > > require licence fees for a CPU architecture or only for a CPU core, e.g. > > for a EDIF netlist? Can I create and use a cleanroom implemenation of a CPU > > architecture without legal problems? > > It also depends on what you intend to do with it. Companies lawyers will > protect their patch - IIRC Atmel sued a phone company, that did what > sounded like 'license creepage' of their AVR core : ie started designs > using the AVR, and then did an ASIC with the same core. Look up the details. > > If your target is FPGA, then only ARM would be likely to go after you. > (as they have small revenue streams via Actel FPGA). > > What sort of core are you looking at doing ? > Why not look at the Mico8 and Mico32 from lattice, and contribute to > that. That is fully opensource, and legal problem free. > You could do a MicoFB, with your pet features... ? > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - AVR cores (developed by 3rd parties) are being used in ASICs and Atmel is not (yet) hunting them. but doing AVR-ASIC in large scale could couse some trouble(attempts) AnttiArticle: 119642
comp.arch.fpga wrote: > No, there is no copyright on CPU architectures. (Speaking of the US > and Germany) > Also, the architecture of the free-ip 6502 is radically different from > the > architecture of the original 6502, so even if there was such a > copyright the 6502 would > likely be not infringing. > Only the ISA is identically, but there also is no copyright on ISAs. Thanks, this sounds very good. I've found a C compiler for the 6502, too, and I will post a link to my website, when I have a working project with my latest TREX board. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119643
Jim Granville wrote: > What sort of core are you looking at doing ? Needs not to be fast, 8 bit registers and 16 bit address space is enough. Should be possible to use internal block RAM and to memory map special locations for accessing hardware, but should be small. It will be used in an FPGA, which is mounted as an extension board to another system, connected by I2C, which has some more VHDL code for accessing some other chips. The core should implement the control logic for interpreting I2C commands for accessing the other chips and providing the result. > Why not look at the Mico8 and Mico32 from lattice, and contribute to > that. That is fully opensource, and legal problem free. > You could do a MicoFB, with your pet features... ? I would like to have a C compiler for it, too. The cc65 compiler for the 6502 looks very mature and feature rich and I already know the 6502 instruction set very well (as an old C64 demo programmer :-) , if I need to implement something in inline assembler, so this was the reason why I think it would be a good choice. I didn't found a C compiler on the mico8 page: http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119644
Thanks for all of the replys,
John you are completly right.. it was because of the grouping
of the adders making the difference.But how?...
why the out=a+b+c+d is not equal to out = (a+b+c)+d;
On May 23, 6:36 pm, John_H <newsgr...@johnhandwork.com> wrote:
> Top posting to avoid the 4 pages of original post, included at the end...
>
> The synthesizers appear generally not to be smart enough to group the
> additions by size first. We can't ask them to do all the work but it
> would have been nice to get better results without the extra nudge. The
> nudge? In Synplify it's called a syn_keep and there's a similar
> attribute in XST (though I know not what it's called.
>
> The specific knowledge of the hardware can be used to get the "best"
> results. Since we know 4-input LUTs are available in the Virtex-4
> (larger in the Virtex-5) it would be "most" efficient to add in1 and in2
> with LUTs then add that result with in3 and have in4 be a carr-in to
> this last add.
>
> While "temp" values are great for readability, there's no guaranteed
> behavior when those values are combinatorial with no directives
> attached; the synthesizer will look at the overall combinatorial "logic
> cone" feeding the output reg.
>
> To get you "best" result, us a 3-bit temp variable
>
> (* syn_keep=1 *) wire [2:0] temp = in1+in2; // Verilog2k attribute syntax
>
> and add this to th 64-bit vector with a carry-in
>
> out <= in3 + temp + in4;
>
> You are NOT guaranteed any build-up order by using the blocking operator
> (=) and should generally use the non-blocking operator for your register
> assignments. There are rare circumstances when the blocking operator is
> useful, but they are rare. The synthesizer will still look at the
> entire logic cone in an attempt to find a "best" solution.
>
> Question: do you intend that a, b, c, and d actually be input registers?
> The blocking operators would have completely ignored the input
> register aspect given the order you coded them if you used out =
> in1+in2+in3+in4; rather than out = result;. As it is, I'm surprised
> both synthesizers gave you input registers. It's for this reason you
> should NOT use the blocking operator!
>
Yes i intentionally made those input registers. This
is the method i follow to generate the worst path using the synplify
tool. The blocking and non blocking assignments not making any
difference in 3 of my codes.
ut as you suggested the "syn_keep" in the second i am getting the
"best" result in both synplify and ISE.
By changing the temp size to 3 itself helped to generate the "best"
result in the ISE(without the KEEP constrains).
> So - let me know what you get with the syn_keep and the non-blocking
> operator. Heck.... maybe the synthesizers will do a better job out of
> the gate without the extra blocking operator confusion.
>
> But be sure to figure out what the equivalent XST attribute is for the
> syn_keep before relying on those results to match the "keep" intent.
>
> - John_H
>
> subint wrote:
> > Hi guys,
> > To know how the synthesizer behave,i wrote logic to add 4
> > vectors in three different ways.And i got differnet result from the
> > synthesizer(used both ISE and synplify).
> > These are the three different approchs i made
> > 1.***************************************************************************************************
> > module add(
> > input clk,
> > input [1:0] a,b,
> > input d,
> > input [63:0] c,
> > output reg [64:0] out
> > );
>
> > reg [1:0] in1,in2;
> > reg in4;
> > reg [63:0] in3;
> > wire [64:0] result;
>
> > always @ (posedge clk) begin
> > {in1,in2,in3,in4}= {a,b,c,d};
> > out= result;
> > end
> > assign result= in1+in2+in3+in4;
>
> > endmodule
> > 2.***************************************************************************************************
> > module add1(
> > input clk,
> > input [1:0] a,b,
> > input d,
> > input [63:0] c,
> > output reg [64:0] out
> > );
>
> > reg [1:0] in1,in2;
> > reg in4;
> > reg [63:0] in3;
> > wire [64:0] temp;
> > wire [64:0] temp2;
> > wire [64:0] result;
>
> > always @ (posedge clk) begin
> > {in1,in2,in3,in4}= {a,b,c,d};
> > out= result;
> > end
>
> > assign temp= in1+in2;
> > assign temp2= temp+in4;
> > assign result= temp2+in3;
>
> > endmodule
> > 3.***************************************************************************************************
> > module add2(
> > input clk,
> > input d,
> > input [1:0] a,b,
> > input [63:0] c,
> > output reg [64:0] out
> > );
>
> > reg [1:0] in1,in2;
> > reg in4;
> > reg [63:0] in3;
> > reg [64:0] result;
>
> > always @ (posedge clk) begin
> > {in1,in2,in3,in4}= {a,b,c,d};
> > out= result;
> > end
> > always @ (*) begin
> > case({in4,in1,in2})
> > 5'b00000: result= in3+3'b000;
> > 5'b00001: result= in3+3'b001;
> > 5'b00010: result= in3+3'b010;
> > 5'b00011: result= in3+3'b011;
> > 5'b00100: result= in3+3'b001;
> > 5'b00101: result= in3+3'b010;
> > 5'b00110: result= in3+3'b011;
> > 5'b00111: result= in3+3'b100;
> > 5'b01000: result= in3+3'b010;
> > 5'b01001: result= in3+3'b011;
> > 5'b01010: result= in3+3'b100;
> > 5'b01011: result= in3+3'b101;
> > 5'b01100: result= in3+3'b011;
> > 5'b01101: result= in3+3'b100;
> > 5'b01110: result= in3+3'b101;
> > 5'b01111: result= in3+3'b110;
>
> > 5'b10000: result= in3+3'b001;
> > 5'b10001: result= in3+3'b010;
> > 5'b10010: result= in3+3'b011;
> > 5'b10011: result= in3+3'b100;
> > 5'b10100: result= in3+3'b010;
> > 5'b10101: result= in3+3'b011;
> > 5'b10110: result= in3+3'b100;
> > 5'b10111: result= in3+3'b101;
> > 5'b11000: result= in3+3'b011;
> > 5'b11001: result= in3+3'b100;
> > 5'b11010: result= in3+3'b101;
> > 5'b11011: result= in3+3'b110;
> > 5'b11100: result= in3+3'b100;
> > 5'b11101: result= in3+3'b101;
> > 5'b11110: result= in3+3'b110;
> > 5'b11111: result= in3+3'b111;
>
> > endcase
> > end
>
> > endmodule
>
> > And the results for these from the ISE are
> > 1.***************************************************************************************************
> > Selected Device : 4vlx15sf363-12
>
> > Number of Slices: 105 out of 6144 1%
> > Number of Slice Flip Flops: 134 out of 12288 1%
> > Number of 4 input LUTs: 128 out of 12288 1%
> > Number of bonded IOBs: 135 out of 240 56%
> > Number of GCLKs: 1 out of 32 3%
>
> > Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
> > Minimum input arrival time before clock: 1.445ns
> > Maximum output required time after clock: 3.921ns
> > Maximum combinational path delay: No path found
>
> > 2.***************************************************************************************************
> > Selected Device : 4vlx15sf363-12
>
> > Number of Slices: 76 out of 6144 1%
> > Number of Slice Flip Flops: 134 out of 12288 1%
> > Number of 4 input LUTs: 72 out of 12288 0%
> > Number of bonded IOBs: 135 out of 240 56%
> > Number of GCLKs: 1 out of 32 3%
>
> > Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
> > Minimum input arrival time before clock: 1.445ns
> > Maximum output required time after clock: 3.921ns
> > Maximum combinational path delay: No path found
> > 3.***************************************************************************************************
> > Selected Device : 4vlx15sf363-12
>
> > Number of Slices: 712 out of 6144 11%
> > Number of Slice Flip Flops: 135 out of 12288 1%
> > Number of 4 input LUTs: 1329 out of 12288 10%
> > Number of bonded IOBs: 135 out of 240 56%
> > Number of GCLKs: 1 out of 32 3%
>
> > Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
> > Minimum input arrival time before clock: 1.459ns
> > Maximum output required time after clock: 3.921ns
> > Maximum combinational path delay: No path found
>
> > *****************************And the Result from the Synplify
> > are*****************************************************************
> > 1.***************************************************************************************************
> > Mapping to part: xc4vlx15sf363-10
> > Cell usage:
> > FD 134 uses
> > GND 1 use
> > MUXCY 1 use
> > MUXCY_L 127 uses
> > XORCY 128 uses
> > LUT1 125 uses
> > LUT2 4 uses
>
> > Mapping Summary:
> > Total LUTs: 129 (1%)
>
> > -----------------------------------------------------------------------------------------------------------------------
> > add|clk 1.0 MHz 143.8 MHz 1000.000
> > 6.952 993.048 inferred Inferred_clkgroup_0
> > =======================================================================================================================
> > 2.***************************************************************************************************
> > Mapping to part: xc4vlx15sf363-10
> > Cell usage:
> > FD 134 uses
> > GND 1 use
> > MUXCY 1 use
> > MUXCY_L 127 uses
> > XORCY 128 uses
> > LUT1 125 uses
> > LUT2 4 uses
>
> > Mapping Summary:
> > Total LUTs: 129 (1%)
>
> > Starting Clock Frequency Frequency Period
> > Period Slack Type Group
> > -----------------------------------------------------------------------------------------------------------------------
> > add1|clk 1.0 MHz 143.8 MHz 1000.000
> > 6.952 993.048 inferred Inferred_clkgroup_0
> > =======================================================================================================================
> > 3.***************************************************************************************************
> > Mapping to part: xc4vlx15sf363-10
> > Cell usage:
> > FD 134 uses
> > GND 1 use
> > MULT_AND 2 uses
> > MUXCY 1 use
> > MUXCY_L 63 uses
> > VCC 1 use
> > XORCY 63 uses
> > LUT1 61 uses
> > LUT2 1 use
> > LUT3 3 uses
> > LUT4 2 uses
>
> > Global Clock Buffers: 1 of 32 (3%)
>
> > -----------------------------------------------------------------------------------------------------------------------
> > add2|clk 1.0 MHz 139.9 MHz 1000.000
> > 7.146 992.854 inferred Inferred_clkgroup_0
>
> > Can any one please help me why i am getting this much difference in
> > the result and what should be the real approch to write in HDL to get
> > most optimised result.
> > Thanks in advance
Article: 119645
Hai sumesh,
The second method is giving me the "best" result.By grouping the
small adders together and adding that with the bigger one actually
reducing the hardware.But i am surprised how it's implementing(without
grouping).
regards
subin
On May 24, 1:44 pm, vssumesh <vssumesh_a...@yahoo.com> wrote:
> and subin i didnt observed the last question......
> what should be the real approch to write in HDL to get most optimised
> result.
> How can one suggest a general method or guideline for coding.... i
> think we can classify it as two separate class....
> 1) general functionalities.... like addition,multiplication,muxing
> etc... i think here we need to code them as direct as u done in the
> first code.... all the synthesizers i hope will have algos to deal
> with that... so no ponit in creating something like 2nd or 3rd coding
> style.... tht looks nt good in the HDL itself....
> 2) The other things are unconventional functionalities... like what we
> implemented in the source formatin switching logic.... we know what to
> do but no machine can translate direct to the optimized HW... so what
> we do we also think abt it and find a way to implement it and code it
> that way.....
> I think when we are coding somrthing we need to differentiate between
> these two class...
Article: 119646How can i command bit Inputs in an FPGA board?Article: 119647
On 24 Mai, 12:16, floris.b...@gmail.com wrote: > How can i command bit Inputs in an FPGA board? you have to say: I command ! AnttiArticle: 119648
On 24 May 2007 03:16:22 -0700, floris.bala@gmail.com wrote: >How can i command bit Inputs in an FPGA board? Bit Inputs: By the left, Quick March! Do you mean "how do I cause pins to become inputs", or "how do I drive my chosen values on to input pins"? Please be a little more clear and specific. -- 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: 119649
<stefan.elmsted@gmail.com> wrote in message news:1179994496.131118.159040@o5g2000hsb.googlegroups.com... > Hi > > I am doing a Spartan3 to Spartan 3 interconnect trough a ribbon (flat) > cable with a characteristic impedance of 173R balanced (103R > unbalanced). > I have tried xilinx webcase to answer on the termination requirements > of LVDS for spartan 3 withhout much luck. I got 2 different answers. > > My questions are: > > 1) Can I use a ribbon cable with 173R balanced characteristic > impedance? I have read that it should be 100R. The transmission is > rather short, 300mm and relative slow in lvds terms. I would rather > not switch the cable since it have other good properities that I rely > on. > Yes. > > 2) With the above cable should the receiver end termination still be > 100R > No. It should match the cable. > > 3) With the above cable is a source resistor network necessary to > match the impedance on the transmitter side and lower reflections? > This is the point where xilinx tend to confuse itself in its > datasheets for spartan 3. My dirty solution with adding 150R series > resisor tend to give nicer signals. > No, it's not necessary. If the receiver is properly terminated, there should be no reflections. BTW, the impedance of the cable seems high. What cable are you using, and in what mode? I.e. GSGSGS or GSSGSSG or has the cable got twisted pairs? G = ground, S = signal. Cheers, Syms.
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