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 Tue, 14 Sep 2010 07:11:35 -0500, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >>> Hmm 4MB/s is very slow for PCI. >> >> >>As above (/below) it's reasonable target performance, no x86 system >>allows you to burst to a target card (seems ridiculous but is the case). >> >>If you want better PCI performance you have to have master functionality >>on your plug in card. >> >>Maximum performance depends you your PC architecture and what else is >>plugged into your PCI bus. I believe that 60-70 MB/s is considered >>a reasonable result for real world systems. >> >> >>Nial. >> > >Hmm 60-70 MB/s would be a very reasonable speed. I would be happy with >40-50MB/s. DO you mean. to achive that speed i would have to use the PCI >master of my PCI card to read and write data from/to the x86 or send data >from the x86 to the card with the PC as a master and send data from the PCI >board to the x86 with the PCI board as a master? I am just curious, whats >speed is achivable with a x1 PCI express bus? Any idea? > Using a Virtex-5 with a x1 PCIe interface (Xilinx ML506 board) using the straight Xilinx PCIe slave implementation, I found I could write to the board at 25MB/s approximately. Reading was another matter - effectively, the host PC writes a request to the board, which then performs a write back to the host. This only gave about 2.5MB/sec. In both cases the same was true - the host cannot initiate burst transfers. I rolled my own simple DMA hardware to generate burst transfers, using the Xilinx PCIe core as a master, and that could read at 150MB/s. I expect to get a little more when I double-buffer, so that DMA can continue into one buffer while the second is being transferred to user code. Xilinx's own DMA cores may or may not work - I can't tell. They are, bizarrely, only available in Verilog, despite multiple independent Webcases requesting VHDL versions. However, rolling a simplified version in VHDL is quick and easy. I don't have a figure for DMA speeds into the card, but expect them to be slightly lower, because the card will have to initiate burst reads. (That means it requests the host to write bursts back to it, which increases the turnround time) You will find a PCI driver for the Raggedstone PCI card on Enterpoint's site. It would be slightly rude to use it on someone else's product, but it may serve as an example for your own driver. I can strongly recommend adding "Essential Linux Device Drivers" (Venkateswaran) to the shopping list. While "LDD" 3rd edition is very good, the two books cover different aspects of driver design and I feel I need both. "ELDD" is also newer; there is much in "LDD" that is out of date, unless you are still using a 2.4 or very early 2.6 kernel. - BrianArticle: 148951
I really don't consider a Xilinx FPGA and Cypress PSoC to be competing technologies, and I think Cypress and Xilinx would agree with me. The programmable logic inside the PSoC is more similar to CPLD logic, and the FPGA doesn't have the analog capability of the PSoC. On this project, the FPGA and PSoC were quite complementary. All of the things that we did with the PSoC are things that the FPGA couldn't do on its own, and the PSoC doesn't have a large amount of programmable logic and related cores and IP, which is why we wanted the FPGA. For example, here are a few things we did with the PSoC that we couldn't do with the FPGA alone: - USB interface - Touch sensitive buttons - Dynamic power measurement of the system power rails - Direct drive of a custom segment LCD - Suspend/Hibernate control of the FPGA Likewise, here are a few things we did with the Spartan-6 that we couldn't do with the PSoC: - Interface to an LPDDR SDRAM (S6 supports up to DDR3) - Embedded ethernet MAC interfaced to external PHY - Interface to 100+ I/Os on the FMC connector - Any number of programmable logic functions that require more than the equivalent logic in ~200 CPLD macrocells - High performance DSP - Native TMDS/HDMI output - High-speed differential signalling - VHDL I think they are both interesting and useful chips to have in your toolbox when considering the needs of your project. I'm not sure about your request for the 32.768 kHz osc, but I will look into it. Bryan > That seems rather bizarre. =A0These boards are done in conjunction with > the chip vendors, no? =A0I would expect Xilinx to never want to be part > of the same promotion as a Cypress PSOC. =A0That wouldn't be a lot > different from sharing a board with Altera or better, an Actel Fusion > part! > > I didn't know the PSOC had digital interfaces other than one used to > boot the chip, I2C I seem to recall. =A0The others are all done in the > programmable digital section I thought. > > What sort of programmable clock to the FPGA? =A0I don't recall seeing a > decent PLL on the PSOC. =A0I guess they can take the main clock and > divide it down in a counter. =A0But that would be pretty lame. =A0If I > need to generate clock rates to the FPGA, I would want more than one > and each one to come from a PLL. =A0But even the real FPGAs don't have > "real" PLLs that can work with a wide range of input and output clock > rates. =A0Cypress makes some clock chips that do that much better, but I > guess that technology is just not compatible with FPGA processes. > > The clock I would really like to see on the PSOC is one that will let > a 32.768 kHz, low power osc set the rate for the very low power (< 2 > uW) battery backed up RTC and also serve as reference for the PLL to > generate the main clocks. =A0I've seen that on just one or two MCUs to > date. =A0An older Atmel ARM MCU even had special I/O to put the system > into low power mode, not just the MCU and be taken back out. =A0That was > a real, real time clock! > > Rick- Hide quoted text - > > - Show quoted text -Article: 148952
On 09/13/2010 09:30 AM, Nial Stewart wrote: >> I have used the pci32lite in a Spartan 3. What I found was that: > >> (1) I couldn't get it to do burst reads, because surprisingly, the PC >> doesn't do burst reads. At least that was the conclusion I came to >> after googling to find out why my linux driver was breaking up burst >> requests into individual transactions. If you want to do burst reads, >> you need master functionality in the PCI IP. Also, iirc, pci32lite >> documentation indicated that it "supports" burst mode by signaling to >> the host system that bursts need to be broken into individually >> transactions. > > AFAIK no x86 based machines will drive burst accesses to plug in > cards. > They can if you mark the memory write combining. -hpaArticle: 148953
>On 09/13/2010 09:30 AM, Nial Stewart wrote: >>> I have used the pci32lite in a Spartan 3. What I found was that: >> >>> (1) I couldn't get it to do burst reads, because surprisingly, the PC >>> doesn't do burst reads. At least that was the conclusion I came to >>> after googling to find out why my linux driver was breaking up burst >>> requests into individual transactions. If you want to do burst reads, >>> you need master functionality in the PCI IP. Also, iirc, pci32lite >>> documentation indicated that it "supports" burst mode by signaling to >>> the host system that bursts need to be broken into individually >>> transactions. >> >> AFAIK no x86 based machines will drive burst accesses to plug in >> cards. >> > >They can if you mark the memory write combining. > > -hpa > But is wirite combining reliable? All i have reared is that lots of problem can happens. Sink --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148954
I'm running some large ModelSim gate level timing simulations which simulate asynchronous inputs coming in through a metastability protected input. The simulation is giving large numbers of timing violation warnings for these inputs which are expected but unwanted for these input gate instances. Does anyone know how I can suppress timing set up and hold warnings for specific instances only? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148955
Hi Austin, About the security of Virtex, I have recently read a document mentioned that the battery charged key can still be read once the battery is removed, since the memory already being charged for too long and a EM field will not easily disappeared. They provided a temperature to EM field lasting prediction as well in their report. There conclusion shows the anti-fuse fpga is the best possible option. What do you think? Ken --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148956
Hi, I m currently working on speech recognition system using the FPGA technology. At first I have to implement audio recording system which will store the audio data into memmory and when the start of speech will be detected (comparing the energy of audio signal, or zero corossing) the system will start to compute the features of audio signal (cepstral coiefficients). I would really need some help with this audio recording system and with recognizing the start of the speech. I have read some material about this stuff but I thing I need some help with first steps of my design. Don't hesitate to ask any further questions. (I am almost sure I haven't give enough information...) Thanks in advance. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148957
Hi to all, I don't understand what is wrong with my design. Can someone give me an idea ? I design a dual microbleze with BSB ( EDK 11.5) : Microblaze_0 + RS232_UART_1 + XPS_timer, Microblaze_1 + XPS_timer, Shared resources: Mutex, Shared_bram and DDR2_SDRAM. After that, I exported hw design to SDK. This it work ok with Xilkernel in SDK, but when I add a FSL conection between the two microblaze, and I try to install Xilkernel in SDK on Microblaze_0, I receive a strange error : Compiling standalone Compiling common Compiling lldma mb-hw.c: In function 'int_system_init': mb-hw.c:143: error: 'XPAR_XPS_INTC_2_DEVICE_ID' undeclared (first use in this function) mb-hw.c:143: error: (Each undeclared identifier is reported only once mb-hw.c:143: error: for each function it appears in.) mb-hw.c:150: error: 'XPAR_XPS_INTC_2_BASEADDR' undeclared (first use in this function) The XPS_intc2 is attached to Microblaze_1, but it gives me this error when I compile Xilkernel for Microblaze_1 ?!?! I don't receive this errors if I use Standalone SO in SDK ( this is because Standalone don't use XPS_Timer ? ) I attached the mhs file. Can someone give me an idea what is wrong? Many thanks, Iulian # ############################################################################## # Created by Base System Builder Wizard for Xilinx EDK 11.5 Build EDK_LS5.70 # Wed Sep 15 11:28:27 2010 # Target Board: Xilinx XUPV5-LX110T Evaluation Platform Rev A # Family: virtex5 # Device: xc5vlx110t # Package: ff1136 # Speed Grade: -1 # Processor number: 2 # Processor 1: microblaze_0 # System clock frequency: 125.0 # Debug Interface: On-Chip HW Debug Module # Processor 2: microblaze_1 # System clock frequency: 125.0 # Debug Interface: On-Chip HW Debug Module # ############################################################################## PARAMETER VERSION = 2.1.0 PORT fpga_0_RS232_Uart_1_RX_pin = fpga_0_RS232_Uart_1_RX_pin, DIR = I PORT fpga_0_RS232_Uart_1_TX_pin = fpga_0_RS232_Uart_1_TX_pin, DIR = O PORT fpga_0_DDR2_SDRAM_DDR2_Clk_pin = fpga_0_DDR2_SDRAM_DDR2_Clk_pin, DIR = O, VEC = [1:0] PORT fpga_0_DDR2_SDRAM_DDR2_Clk_n_pin = fpga_0_DDR2_SDRAM_DDR2_Clk_n_pin, DIR = O, VEC = [1:0] PORT fpga_0_DDR2_SDRAM_DDR2_CE_pin = fpga_0_DDR2_SDRAM_DDR2_CE_pin, DIR = O, VEC = [1:0] PORT fpga_0_DDR2_SDRAM_DDR2_CS_n_pin = fpga_0_DDR2_SDRAM_DDR2_CS_n_pin, DIR = O, VEC = [1:0] PORT fpga_0_DDR2_SDRAM_DDR2_ODT_pin = fpga_0_DDR2_SDRAM_DDR2_ODT_pin, DIR = O, VEC = [1:0] PORT fpga_0_DDR2_SDRAM_DDR2_RAS_n_pin = fpga_0_DDR2_SDRAM_DDR2_RAS_n_pin, DIR = O PORT fpga_0_DDR2_SDRAM_DDR2_CAS_n_pin = fpga_0_DDR2_SDRAM_DDR2_CAS_n_pin, DIR = O PORT fpga_0_DDR2_SDRAM_DDR2_WE_n_pin = fpga_0_DDR2_SDRAM_DDR2_WE_n_pin, DIR = O PORT fpga_0_DDR2_SDRAM_DDR2_BankAddr_pin = fpga_0_DDR2_SDRAM_DDR2_BankAddr_pin, DIR = O, VEC = [1:0] PORT fpga_0_DDR2_SDRAM_DDR2_Addr_pin = fpga_0_DDR2_SDRAM_DDR2_Addr_pin, DIR = O, VEC = [12:0] PORT fpga_0_DDR2_SDRAM_DDR2_DQ_pin = fpga_0_DDR2_SDRAM_DDR2_DQ_pin, DIR = IO, VEC = [63:0] PORT fpga_0_DDR2_SDRAM_DDR2_DM_pin = fpga_0_DDR2_SDRAM_DDR2_DM_pin, DIR = O, VEC = [7:0] PORT fpga_0_DDR2_SDRAM_DDR2_DQS_pin = fpga_0_DDR2_SDRAM_DDR2_DQS_pin, DIR = IO, VEC = [7:0] PORT fpga_0_DDR2_SDRAM_DDR2_DQS_n_pin = fpga_0_DDR2_SDRAM_DDR2_DQS_n_pin, DIR = IO, VEC = [7:0] PORT fpga_0_clk_1_sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ = 100000000 PORT fpga_0_rst_1_sys_rst_pin = sys_rst_s, DIR = I, SIGIS = RST, RST_POLARITY = 0 BEGIN microblaze PARAMETER INSTANCE = microblaze_0 PARAMETER C_INTERCONNECT = 1 PARAMETER C_DEBUG_ENABLED = 1 PARAMETER HW_VER = 7.20.d PARAMETER C_FSL_LINKS = 1 BUS_INTERFACE DPLB = mb_plb BUS_INTERFACE IPLB = mb_plb BUS_INTERFACE DEBUG = microblaze_0_mdm_bus BUS_INTERFACE DLMB = dlmb BUS_INTERFACE ILMB = ilmb BUS_INTERFACE SFSL0 = fsl_v20_1 BUS_INTERFACE MFSL0 = fsl_v20_0 PORT MB_RESET = mb_reset PORT INTERRUPT = microblaze_0_Interrupt END BEGIN plb_v46 PARAMETER INSTANCE = mb_plb PARAMETER HW_VER = 1.04.a PORT PLB_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN lmb_v10 PARAMETER INSTANCE = ilmb PARAMETER HW_VER = 1.00.a PORT LMB_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN lmb_v10 PARAMETER INSTANCE = dlmb PARAMETER HW_VER = 1.00.a PORT LMB_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = dlmb_cntlr PARAMETER HW_VER = 2.10.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001fff BUS_INTERFACE SLMB = dlmb BUS_INTERFACE BRAM_PORT = dlmb_port END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = ilmb_cntlr PARAMETER HW_VER = 2.10.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001fff BUS_INTERFACE SLMB = ilmb BUS_INTERFACE BRAM_PORT = ilmb_port END BEGIN bram_block PARAMETER INSTANCE = lmb_bram PARAMETER HW_VER = 1.00.a BUS_INTERFACE PORTA = ilmb_port BUS_INTERFACE PORTB = dlmb_port END BEGIN microblaze PARAMETER INSTANCE = microblaze_1 PARAMETER C_INTERCONNECT = 1 PARAMETER C_DEBUG_ENABLED = 1 PARAMETER HW_VER = 7.20.d PARAMETER C_FSL_LINKS = 1 BUS_INTERFACE DPLB = mb_plb_1 BUS_INTERFACE IPLB = mb_plb_1 BUS_INTERFACE DEBUG = microblaze_1_mdm_bus BUS_INTERFACE DLMB = dlmb_1 BUS_INTERFACE ILMB = ilmb_1 BUS_INTERFACE SFSL0 = fsl_v20_0 BUS_INTERFACE MFSL0 = fsl_v20_1 PORT MB_RESET = mb_reset PORT INTERRUPT = microblaze_1_Interrupt END BEGIN plb_v46 PARAMETER INSTANCE = mb_plb_1 PARAMETER HW_VER = 1.04.a PORT PLB_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN lmb_v10 PARAMETER INSTANCE = ilmb_1 PARAMETER HW_VER = 1.00.a PORT LMB_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN lmb_v10 PARAMETER INSTANCE = dlmb_1 PARAMETER HW_VER = 1.00.a PORT LMB_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = dlmb_cntlr_1 PARAMETER HW_VER = 2.10.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001fff BUS_INTERFACE SLMB = dlmb_1 BUS_INTERFACE BRAM_PORT = dlmb_port_1 END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = ilmb_cntlr_1 PARAMETER HW_VER = 2.10.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001fff BUS_INTERFACE SLMB = ilmb_1 BUS_INTERFACE BRAM_PORT = ilmb_port_1 END BEGIN bram_block PARAMETER INSTANCE = lmb_bram_1 PARAMETER HW_VER = 1.00.a BUS_INTERFACE PORTA = ilmb_port_1 BUS_INTERFACE PORTB = dlmb_port_1 END BEGIN xps_mutex PARAMETER INSTANCE = xps_mutex_0 PARAMETER C_ASYNC_CLKS = 0 PARAMETER HW_VER = 1.00.d PARAMETER C_SPLB0_BASEADDR = 0x82400000 PARAMETER C_SPLB0_HIGHADDR = 0x8240ffff PARAMETER C_SPLB1_BASEADDR = 0x82600000 PARAMETER C_SPLB1_HIGHADDR = 0x8260ffff BUS_INTERFACE SPLB0 = mb_plb BUS_INTERFACE SPLB1 = mb_plb_1 END BEGIN xps_uartlite PARAMETER INSTANCE = RS232_Uart_1 PARAMETER C_BAUDRATE = 9600 PARAMETER C_DATA_BITS = 8 PARAMETER C_USE_PARITY = 0 PARAMETER C_ODD_PARITY = 0 PARAMETER HW_VER = 1.01.a PARAMETER C_BASEADDR = 0x84000000 PARAMETER C_HIGHADDR = 0x8400ffff BUS_INTERFACE SPLB = mb_plb PORT RX = fpga_0_RS232_Uart_1_RX_pin PORT TX = fpga_0_RS232_Uart_1_TX_pin END BEGIN xps_timer PARAMETER INSTANCE = xps_timer_0 PARAMETER C_COUNT_WIDTH = 32 PARAMETER C_ONE_TIMER_ONLY = 0 PARAMETER HW_VER = 1.01.b PARAMETER C_BASEADDR = 0x83c00000 PARAMETER C_HIGHADDR = 0x83c0ffff BUS_INTERFACE SPLB = mb_plb PORT Interrupt = xps_timer_0_Interrupt END BEGIN xps_timer PARAMETER INSTANCE = xps_timer_1 PARAMETER C_COUNT_WIDTH = 32 PARAMETER C_ONE_TIMER_ONLY = 0 PARAMETER HW_VER = 1.01.b PARAMETER C_BASEADDR = 0x83c00000 PARAMETER C_HIGHADDR = 0x83c0ffff BUS_INTERFACE SPLB = mb_plb_1 PORT Interrupt = xps_timer_1_Interrupt END BEGIN mpmc PARAMETER INSTANCE = DDR2_SDRAM PARAMETER C_NUM_PORTS = 2 PARAMETER C_NUM_IDELAYCTRL = 3 PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y6-IDELAYCTRL_X0Y2-IDELAYCTRL_X0Y1 PARAMETER C_MEM_PARTNO = mt4htf3264h-53e PARAMETER C_MEM_ODT_TYPE = 1 PARAMETER C_MEM_CLK_WIDTH = 2 PARAMETER C_MEM_ODT_WIDTH = 2 PARAMETER C_MEM_CE_WIDTH = 2 PARAMETER C_MEM_CS_N_WIDTH = 2 PARAMETER C_DDR2_DQSN_ENABLE = 1 PARAMETER C_PIM0_BASETYPE = 2 PARAMETER C_PIM1_BASETYPE = 2 PARAMETER HW_VER = 5.04.a PARAMETER C_MPMC_BASEADDR = 0x90000000 PARAMETER C_MPMC_HIGHADDR = 0x9fffffff BUS_INTERFACE SPLB0 = mb_plb BUS_INTERFACE SPLB1 = mb_plb_1 PORT MPMC_Clk0 = clk_125_0000MHzPLL0 PORT MPMC_Clk0_DIV2 = clk_62_5000MHzPLL0 PORT MPMC_Clk90 = clk_125_0000MHz90PLL0 PORT MPMC_Clk_200MHz = clk_200_0000MHz PORT MPMC_Rst = sys_periph_reset PORT DDR2_Clk = fpga_0_DDR2_SDRAM_DDR2_Clk_pin PORT DDR2_Clk_n = fpga_0_DDR2_SDRAM_DDR2_Clk_n_pin PORT DDR2_CE = fpga_0_DDR2_SDRAM_DDR2_CE_pin PORT DDR2_CS_n = fpga_0_DDR2_SDRAM_DDR2_CS_n_pin PORT DDR2_ODT = fpga_0_DDR2_SDRAM_DDR2_ODT_pin PORT DDR2_RAS_n = fpga_0_DDR2_SDRAM_DDR2_RAS_n_pin PORT DDR2_CAS_n = fpga_0_DDR2_SDRAM_DDR2_CAS_n_pin PORT DDR2_WE_n = fpga_0_DDR2_SDRAM_DDR2_WE_n_pin PORT DDR2_BankAddr = fpga_0_DDR2_SDRAM_DDR2_BankAddr_pin PORT DDR2_Addr = fpga_0_DDR2_SDRAM_DDR2_Addr_pin PORT DDR2_DQ = fpga_0_DDR2_SDRAM_DDR2_DQ_pin PORT DDR2_DM = fpga_0_DDR2_SDRAM_DDR2_DM_pin PORT DDR2_DQS = fpga_0_DDR2_SDRAM_DDR2_DQS_pin PORT DDR2_DQS_n = fpga_0_DDR2_SDRAM_DDR2_DQS_n_pin END BEGIN xps_bram_if_cntlr PARAMETER INSTANCE = shared_bram_if_cntlr_0_top PARAMETER C_SPLB_NATIVE_DWIDTH = 32 PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x8a008000 PARAMETER C_HIGHADDR = 0x8a009fff BUS_INTERFACE SPLB = mb_plb BUS_INTERFACE PORTA = shared_bram_if_cntlr_0_bram_block_PortA END BEGIN xps_bram_if_cntlr PARAMETER INSTANCE = shared_bram_if_cntlr_0_bottom PARAMETER C_SPLB_NATIVE_DWIDTH = 32 PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x8a008000 PARAMETER C_HIGHADDR = 0x8a009fff BUS_INTERFACE SPLB = mb_plb_1 BUS_INTERFACE PORTA = shared_bram_if_cntlr_0_bram_block_PortB END BEGIN bram_block PARAMETER INSTANCE = shared_bram_if_cntlr_0_bram_block PARAMETER HW_VER = 1.00.a BUS_INTERFACE PORTA = shared_bram_if_cntlr_0_bram_block_PortA BUS_INTERFACE PORTB = shared_bram_if_cntlr_0_bram_block_PortB END BEGIN clock_generator PARAMETER INSTANCE = clock_generator_0 PARAMETER C_EXT_RESET_HIGH = 0 PARAMETER C_CLKIN_FREQ = 100000000 PARAMETER C_CLKOUT0_FREQ = 125000000 PARAMETER C_CLKOUT0_PHASE = 90 PARAMETER C_CLKOUT0_GROUP = PLL0 PARAMETER C_CLKOUT0_BUF = TRUE PARAMETER C_CLKOUT1_FREQ = 125000000 PARAMETER C_CLKOUT1_PHASE = 0 PARAMETER C_CLKOUT1_GROUP = PLL0 PARAMETER C_CLKOUT1_BUF = TRUE PARAMETER C_CLKOUT2_FREQ = 200000000 PARAMETER C_CLKOUT2_PHASE = 0 PARAMETER C_CLKOUT2_GROUP = NONE PARAMETER C_CLKOUT2_BUF = TRUE PARAMETER C_CLKOUT3_FREQ = 62500000 PARAMETER C_CLKOUT3_PHASE = 0 PARAMETER C_CLKOUT3_GROUP = PLL0 PARAMETER C_CLKOUT3_BUF = TRUE PARAMETER HW_VER = 3.02.a PORT CLKIN = dcm_clk_s PORT CLKOUT0 = clk_125_0000MHz90PLL0 PORT CLKOUT1 = clk_125_0000MHzPLL0 PORT CLKOUT2 = clk_200_0000MHz PORT CLKOUT3 = clk_62_5000MHzPLL0 PORT RST = sys_rst_s PORT LOCKED = Dcm_all_locked END BEGIN mdm PARAMETER INSTANCE = mdm_0 PARAMETER C_MB_DBG_PORTS = 2 PARAMETER C_USE_UART = 1 PARAMETER C_UART_WIDTH = 8 PARAMETER HW_VER = 1.00.g PARAMETER C_BASEADDR = 0x84400000 PARAMETER C_HIGHADDR = 0x8440ffff BUS_INTERFACE SPLB = mb_plb_1 BUS_INTERFACE MBDEBUG_0 = microblaze_0_mdm_bus BUS_INTERFACE MBDEBUG_1 = microblaze_1_mdm_bus PORT Debug_SYS_Rst = Debug_SYS_Rst END BEGIN proc_sys_reset PARAMETER INSTANCE = proc_sys_reset_0 PARAMETER C_EXT_RESET_HIGH = 0 PARAMETER HW_VER = 2.00.a PORT Slowest_sync_clk = clk_125_0000MHzPLL0 PORT Ext_Reset_In = sys_rst_s PORT MB_Debug_Sys_Rst = Debug_SYS_Rst PORT Dcm_locked = Dcm_all_locked PORT MB_Reset = mb_reset PORT Bus_Struct_Reset = sys_bus_reset PORT Peripheral_Reset = sys_periph_reset END BEGIN xps_intc PARAMETER INSTANCE = xps_intc_0 PARAMETER HW_VER = 2.00.a PARAMETER C_BASEADDR = 0x81800000 PARAMETER C_HIGHADDR = 0x8180ffff BUS_INTERFACE SPLB = mb_plb PORT Intr = xps_timer_0_Interrupt PORT Irq = microblaze_0_Interrupt END BEGIN xps_intc PARAMETER INSTANCE = xps_intc_2 PARAMETER HW_VER = 2.00.a PARAMETER C_BASEADDR = 0x81800000 PARAMETER C_HIGHADDR = 0x8180ffff BUS_INTERFACE SPLB = mb_plb_1 PORT Intr = xps_timer_1_Interrupt PORT Irq = microblaze_1_Interrupt END BEGIN fsl_v20 PARAMETER INSTANCE = fsl_v20_0 PARAMETER HW_VER = 2.11.b PORT FSL_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END BEGIN fsl_v20 PARAMETER INSTANCE = fsl_v20_1 PARAMETER HW_VER = 2.11.b PORT FSL_Clk = clk_125_0000MHzPLL0 PORT SYS_Rst = sys_bus_reset END --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148958
On Sep 15, 9:43=A0am, "agb" <andy.bradford@n_o_s_p_a_m.ultra-ccs.com> wrote: > I'm running some large ModelSim gate level timing simulations which > simulate asynchronous inputs coming in through a metastability protected > input. The simulation is giving large numbers of timing violation warning= s > for these inputs which are expected but unwanted for these input gate > instances. > Does anyone know how I can suppress timing set up and hold warnings for > specific instances only? > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You did not mention which brand of FPGA you are using. For Xilinx, you can use the ASYNC_REG constraint on your synchronizing registers. I know that it stops the propagation of 'X's when the input timing is violated and I believe that it also suppresses the warnings. See the Xilinx constraint guide for all the details. Regards, John McCaskill www.FasterTechnology.comArticle: 148959
"agb" <andy.bradford@n_o_s_p_a_m.ultra-ccs.com> wrote in message news:qM2dncyECLMdRg3RnZ2dnUVZ_qydnZ2d@giganews.com... > I'm running some large ModelSim gate level timing simulations which > simulate asynchronous inputs coming in through a metastability protected > input. The simulation is giving large numbers of timing violation warnings > for these inputs which are expected but unwanted for these input gate > instances. > Does anyone know how I can suppress timing set up and hold warnings for > specific instances only? If you are running Modelsim SE or Questa you can use the tcheck_set/tcheck_status command (see Reference manual) Hans www.ht-lab.comArticle: 148960
On Sep 15, 7:43=A0am, "kenS" <skypulse1@n_o_s_p_a_m.hotmail.com> wrote: > Hi Austin, > > About the security of Virtex, I have recently read a document mentioned > that the battery charged key can still be read once the battery is remove= d, > since the memory already being charged for too long and a EM field will n= ot > easily disappeared. They provided a temperature to EM field lasting > prediction as well in their report. There conclusion shows the anti-fuse > fpga is the best possible option. What do you think? > > Ken > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Can you post a link to this document? Or provide more details on what the author had to go through to be able to read the "ghost" EM field of the security bits? At first glance this doesn't seem very plausible. Ed McGettigan -- Xilinx Inc.Article: 148961
Hi All, I want to provide evaluation versions of my IP, targeted at Xilinx, Altera, etc., without giving out the VHDL source. AFAIK, I can synthesize to netlist and distribute the netlist, and the netlist will cover at least a family of parts. Are there any guides available to get me started? -BradArticle: 148962
Hi everybody,
Sorry if this is a basic question.
I'm trying to implement a interrupt handler for the UARTLite in my
mBlaze system. The chain is: mBlaze->IntCtrl->Uart. The IntCtrl is to
add future interrupt sources. I'm using as an example the code from
XAPP808 - FPGA Motor Control Reference Design by Craig Hackney.
What I don't understand is the actual handler structure. It looks like
this:
void serialCommRecv (void *param, unsigned int byteCount)
{
do
{
// do something
} while ((byteCount = XUartLite_Recv(( XUartLite * ) param,
charBuffer, 1)));
}
I don't understand what are the handler function arguments values when
the function is called and what is the purpose of using arguments in a
handler? Can anyone explain that to me?
Tanks,
mariano
Article: 148963Hi Brad, Have you considered mangling your source code.It provides less protection comparing to netlist, but might be sufficient in your case. I've seen at least one large semiconductor company that distributed their IP cores that way. VCS has -Xmangle option to do that. There are other tools to do VHDL mangling/obfuscation. Thanks, EvgeniArticle: 148964
You don't need to tell me what the PSOC can do. I am very aware of how the original PSOC was logic limited. But the PSOC3/5 is much less so. They may not have tons of logic on them, but Xilinx doesn't just sell FPGAs, they also sell CPLDs. The PSOC3/5 will compete very effectively against an MCU/FPGA/analog combination and in fact, that is exactly the market they are looking to capture. As to the combination being useful, I am sure there are a very few applications where you might want to use a PSOC3/5 in conjunction with an FPGA. But you are not really taking full advantage of the PSOC3/5 at that point and these will be rare applications. The real concern is that Cypress is opening a market for the combo chips that Xilinx has no real experience with. I expect Xilinx is keeping their nose to the wind on this and will jump in if they see it as a significant market. Personally, I see integrated devices like this as the next "big" thing. Let's face it. The need for larger FPGAs is diminishing as they have reached nearly a million LUTs (not withstanding the Xilinx inflation factor). The number of designs that need such large devices is getting to be a small fraction of the total market and the FPGA makers want to get their chips in general consumer items. MCUs are fine, but it is hard to do everything in software sometimes. So a device with a combination of software and programmable hardware will be the cutting edge for these new, low price markets. If Xilinx is really as smart as they should be, I can't imagine they don't have something like a PSOC3/5 in the wings. I expect they are waiting for Cypress and Actel to open the market for them. Then they will come in like the 600 lb gorilla and sit where they wish. Rick On Sep 14, 10:25 pm, Bryan <bryan.fletc...@avnet.com> wrote: > I really don't consider a Xilinx FPGA and Cypress PSoC to be competing > technologies, and I think Cypress and Xilinx would agree with me. The > programmable logic inside the PSoC is more similar to CPLD logic, and > the FPGA doesn't have the analog capability of the PSoC. On this > project, the FPGA and PSoC were quite complementary. All of the > things that we did with the PSoC are things that the FPGA couldn't do > on its own, and the PSoC doesn't have a large amount of programmable > logic and related cores and IP, which is why we wanted the FPGA. > > For example, here are a few things we did with the PSoC that we > couldn't do with the FPGA alone: > - USB interface > - Touch sensitive buttons > - Dynamic power measurement of the system power rails > - Direct drive of a custom segment LCD > - Suspend/Hibernate control of the FPGA > > Likewise, here are a few things we did with the Spartan-6 that we > couldn't do with the PSoC: > - Interface to an LPDDR SDRAM (S6 supports up to DDR3) > - Embedded ethernet MAC interfaced to external PHY > - Interface to 100+ I/Os on the FMC connector > - Any number of programmable logic functions that require more than > the equivalent logic in ~200 CPLD macrocells > - High performance DSP > - Native TMDS/HDMI output > - High-speed differential signalling > - VHDL > > I think they are both interesting and useful chips to have in your > toolbox when considering the needs of your project. > > I'm not sure about your request for the 32.768 kHz osc, but I will > look into it. > > Bryan > > > That seems rather bizarre. These boards are done in conjunction with > > the chip vendors, no? I would expect Xilinx to never want to be part > > of the same promotion as a Cypress PSOC. That wouldn't be a lot > > different from sharing a board with Altera or better, an Actel Fusion > > part! > > > I didn't know the PSOC had digital interfaces other than one used to > > boot the chip, I2C I seem to recall. The others are all done in the > > programmable digital section I thought. > > > What sort of programmable clock to the FPGA? I don't recall seeing a > > decent PLL on the PSOC. I guess they can take the main clock and > > divide it down in a counter. But that would be pretty lame. If I > > need to generate clock rates to the FPGA, I would want more than one > > and each one to come from a PLL. But even the real FPGAs don't have > > "real" PLLs that can work with a wide range of input and output clock > > rates. Cypress makes some clock chips that do that much better, but I > > guess that technology is just not compatible with FPGA processes. > > > The clock I would really like to see on the PSOC is one that will let > > a 32.768 kHz, low power osc set the rate for the very low power (< 2 > > uW) battery backed up RTC and also serve as reference for the PLL to > > generate the main clocks. I've seen that on just one or two MCUs to > > date. An older Atmel ARM MCU even had special I/O to put the system > > into low power mode, not just the MCU and be taken back out. That was > > a real, real time clock! > > > Rick- Hide quoted text - > > > - Show quoted text - > >Article: 148965
On Sep 15, 3:40=A0am, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >On 09/13/2010 09:30 AM, Nial Stewart wrote: > >>> I have used the pci32lite in a Spartan 3. What I found was that: > > >>> (1) I couldn't get it to do burst reads, because surprisingly, the PC > >>> doesn't do burst reads. At least that was the conclusion I came to > >>> after googling to find out why my linux driver was breaking up burst > >>> requests into individual transactions. If you want to do burst reads, > >>> you need master functionality in the PCI IP. Also, iirc, pci32lite > >>> documentation indicated that it "supports" burst mode by signaling to > >>> the host system that bursts need to be broken into individually > >>> transactions. > > >> AFAIK no x86 based machines will drive burst accesses to plug in > >> cards. > > >They can if you mark the memory write combining. > > > =A0 =A0-hpa > > But is wirite combining reliable? All i have reared is that lots of probl= em > can happens. > > Sink =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hi, Here is my experience with developing a 64-bit/66MHz PCI core and multiple products relating with the core design, using both Altera chip Flex 20K(?) and Xilinx Virtex II-1000. The testing data rate from our client report was: 480MB/s. I was not involved in the testing procedure. Later I developed a new version which can run 528MB/s, but failed to implement in a board, because the original board was wired in such a way that it didn't recognize different enable signals from two different CE. 1. Altera chip Flex 20K had big layout issue to meet 66MHz for both IRDY and TRDY pins. FRAME and STOP were never a problem in my design. Each code changes needed 1 week to do layout manually to make them meet 66MHz. The time spent entirely on IRDY and TRDY pins. The state machines for Master or Slave were both written using Altera ASM(?) language that makes the layout manually possible. After losing a big customer due to the 1-week manually layout, the company decided to switch to Xilinx Virtex II-1000. 2. Xilinx has an invention about how to generate IRDY and TRDY signals in the US patent :6218864_Xilinx-Structure and method for generating a clock enable signal in a PLD.pdf http://www.google.com/patents/about?id=3DDnwGAAAAEBAJ&dq=3DPCI,+IRDY,+TRDY+= inassignee:Xilinx&as_drrb_ap=3Dq&as_minm_ap=3D0&as_miny_ap=3D&as_maxm_ap=3D= 0&as_maxy_ap=3D&as_drrb_is=3Dq&as_minm_is=3D0&as_miny_is=3D&as_maxm_is=3D0&= as_maxy_is=3D&num=3D100 After my design was transferred from Altera to Xilinx, the final running frequency can be reached up to 68MHz after one compilation without big efforts, and even one military product occupies 90% LUT space and it still runs above 66MHz. 3. Because Xilinx doesn't provide a low program language similar to Altera's, both the master state machine and slave state machine must be carefully rewritten and kept in an independent module to compile, otherwise it couldn't meet the 66MHz running frequency. From two companies' practice dealing with PCI bus, I found Altera was always one step slower than Xilinx. After PCI core implementation, it was very clear that IRDY and TRDY had combinational heavy burdens, Altera did nothing to invent something to improve it, but Xilinx did find something useful for a patent and it works well at least in my case. This invention is good, but not the best. I had a best invention for it, but it was too later for an invention to be useful. Because PCI bus had been outdated. 4. Xilinx is excellent in developing new technology. Its new technology may be fast to apply for patents, but not always the best in ASIC field. But the two best and most important inventions in FPGA field are Xilinx inventions: 1. Using memory address to get its function. 2: Introducing carry-in structure in FPGA field. Altera had a motto when one opened its software: What you can do, we can do better. At first I thought it was a good statement when dealing with my manually layout for PCI bus, after switching to Xilinx chip, I changed my mind and thought it was a real shameful motto, compared with Xilinx efforts in the same field. In the PCI bus respect, I thought Altera was a loser. WengArticle: 148966
On 15 Sep., 16:44, "shimon001" <shimon001@n_o_s_p_a_m.gmail.com> wrote: > Hi, I m currently working on speech recognition system using the FPGA > technology. > > At first I have to implement audio recording system which will store the > audio data into memmory and when the start of speech will be detected > (comparing the energy of audio signal, or zero corossing) the system will > start to compute the features of audio signal (cepstral coiefficients). > > I would really need some help with this audio recording system and with > recognizing the start of the speech. > > I have read some material about this stuff but I thing I need some help > with first steps of my design. > > Don't hesitate to ask any further questions. (I am almost sure I haven't > give enough information...) > Thanks in advance. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hi, doing some audio recording is not so complicated. Just grabbing some samples and putting them into some RAM. First question that arises: Do you already have some hardware that you are going to work with? What shall be the source for your audio signals? Some microphone on an ADC, or some sort of digital interface? Once your hardware is defined, you can design the interface part. And what shall happen, when you finally got some data in the RAM? How will you check the successful recording? Have a nice synthesis EilertArticle: 148967
> In the PCI bus respect, I thought Altera was a loser. In Altera's defence this must have been a good few years ago, the Flex devices haven't been 'current' for a while. And comparing a flex device with a Virtex you're comparing a low cost device with a much more expensive part! These days I'd expect _any_ FPGA to fairly easily meet 33MHz 32 Bits and any current Stratix or Virtex to meet 66MHz 64 Bits. Nial.Article: 148968
On Sep 16, 2:54=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > In the PCI bus respect, I thought Altera was a loser. > > In Altera's defence this must have been a good few years ago, the Flex de= vices > haven't been 'current' for a while. > > And comparing a flex device with a Virtex you're comparing a low cost > device with a much more expensive part! > > These days I'd expect _any_ FPGA to fairly easily meet 33MHz 32 Bits and > any current Stratix or Virtex to meet 66MHz 64 Bits. > > Nial. 1. The chip switch from Flex 20K to Virtex II occurs in 2003. At that time, I thought both were at the same level of technology. And I heard that the price of Virtex II -1000 was even lower than Flex 20K's at the time. Maybe there was a promotion selling scheme behind the door by Xilinx to encourage customers to switch to its products. 2. Running frequency is a lifeline: death or live. No matter how good your design is, when it fails to reach the specified running frequency, all is dead. When redesigning with a new military product, the LUT space usage in Virtex II was above 93%. At that time, one can imagine that if everything went well except the running frequency, the product board had to be redesigned, chips had to be reselected and deadline would be rescheduled and a big penalty was pending. fortuitously after several fine tuning of compilation parameters, using Xilinx ISE 8.x, it passed the 66.7MHz running frequency, but it never passed above 66.7MHz using Xlinx ISE 9.x when a colleague tried to confirm the running frequency using the latest version of ISE 9.x. 3. The PCI legacy circuits from both Altera and Xilinx go into their advanced structures of their next generations, but the shortcoming with Altera handling PCI bus method doesn't go away as you claim. It costs a lot of route resources to get the 66MHz. When LUT space is being used up, the problem will pop up and goes after you. I would like to provide more information about the chip switch. 4. The same design using Flex 20K by Altera got about 56MHz running frequency, and I had to spend 1 week to manually layout to get it over 66.7MHz. All critical paths are IRDY and TRDY. 5. The same design using Virtex II by Xilinx usually got 67MHz or above running frequency after first compilation. WengArticle: 148969
> 4. The same design using Flex 20K by Altera got about 56MHz running > frequency, and I had to spend 1 week to manually layout to get it over > 66.7MHz. All critical paths are IRDY and TRDY. > 5. The same design using Virtex II by Xilinx usually got 67MHz or > above running frequency after first compilation. Do you mean Apex20K? That was released in 1998, I can't find the date for the Virtex II release but it was 2001/2002 I think which makes it the next generation of devices. If you're comparing a Flex20K with a VirtexII you're comparing a low cost device with a top of the range device which again isn't a fair comparison. Anyway this isn't really helping the OP with his queries. Nial.Article: 148970
>Hi, I m currently working on speech recognition system using the FPGA >technology. > >At first I have to implement audio recording system which will store the >audio data into memmory and when the start of speech will be detected >(comparing the energy of audio signal, or zero corossing) the system will >start to compute the features of audio signal (cepstral coiefficients). > I hope your FPGA has lots of DSP resources on it! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148971
I've put a new release of hdlmaker on the web, http://www.polybus.com/hdlmaker/users_guide/index.htm HDLmaker generates Verilog, VHDL as well as simulation and synthesis scripts. This version has a few new features, support of the latest Altera and Xilinx FPGAs. It also supports Actel and Achronix FPGAs. HDLmaker is free software, it's licensed under the BSD.Article: 148972
Hi, It'd be very convenient to post the manual in PDF or HTML format online instead of requiring tool installation. Thanks, EvgeniArticle: 148973
On Thu, 16 Sep 2010 17:25:26 -0700, OutputLogic wrote: > Hi, > > It'd be very convenient to post the manual in PDF or HTML format online > instead of requiring tool installation. > > Thanks, > Evgeni The manual is online. I admit that it's pretty mediocre, one of these days I'll take the time to rewrite it. http://www.polybus.com/hdlmaker/users_guide/id20.htm http://www.polybus.com/hdlmaker/users_guide/id18.htmArticle: 148974
>"agb" <andy.bradford@n_o_s_p_a_m.ultra-ccs.com> wrote in message >news:qM2dncyECLMdRg3RnZ2dnUVZ_qydnZ2d@giganews.com... >> I'm running some large ModelSim gate level timing simulations which >> simulate asynchronous inputs coming in through a metastability protected >> input. The simulation is giving large numbers of timing violation warnings >> for these inputs which are expected but unwanted for these input gate >> instances. >> Does anyone know how I can suppress timing set up and hold warnings for >> specific instances only? > >If you are running Modelsim SE or Questa you can use the >tcheck_set/tcheck_status command (see Reference manual) > >Hans >www.ht-lab.com > > Thanks, but unfortunately I'm running ModelSim PE and implementing on an Actel ProAsic Plus FPGA --------------------------------------- Posted through http://www.FPGARelated.com
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z