Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 148950

Article: 148950
Subject: Re: Question about OC PCI Cores
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 15 Sep 2010 00:54:57 +0100
Links: << >>  << T >>  << A >>
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.

- Brian

Article: 148951
Subject: Re: PSOC3/5
From: Bryan <bryan.fletcher@avnet.com>
Date: Tue, 14 Sep 2010 19:25:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Question about OC PCI Cores
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Tue, 14 Sep 2010 21:55:13 -0700
Links: << >>  << T >>  << A >>
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

Article: 148953
Subject: Re: Question about OC PCI Cores
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Wed, 15 Sep 2010 05:40:14 -0500
Links: << >>  << T >>  << A >>
>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.com

Article: 148954
Subject: Preventing timing warnings
From: "agb" <andy.bradford@n_o_s_p_a_m.ultra-ccs.com>
Date: Wed, 15 Sep 2010 09:43:12 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 148955
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: "kenS" <skypulse1@n_o_s_p_a_m.hotmail.com>
Date: Wed, 15 Sep 2010 09:43:32 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 148956
Subject: FPGA speech recongintion system
From: "shimon001" <shimon001@n_o_s_p_a_m.gmail.com>
Date: Wed, 15 Sep 2010 09:44:21 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 148957
Subject: Problem with FSL, Dual Microblaze and Xilkernel.
From: "cristal" <iulian.nita@n_o_s_p_a_m.upb.ro>
Date: Wed, 15 Sep 2010 09:44:27 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 148958
Subject: Re: Preventing timing warnings
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 15 Sep 2010 08:21:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com

Article: 148959
Subject: Re: Preventing timing warnings
From: "HT-Lab" <hans64@ht-lab.com>
Date: Wed, 15 Sep 2010 16:30:47 +0100
Links: << >>  << T >>  << A >>
"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




Article: 148960
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 15 Sep 2010 08:45:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Providing FPGA-specific evaluation IP
From: Brad <hwfwguy@gmail.com>
Date: Wed, 15 Sep 2010 10:07:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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?

-Brad

Article: 148962
Subject: interrupt handler arguments
From: jmariano <jmariano65@gmail.com>
Date: Wed, 15 Sep 2010 14:41:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 148963
Subject: Re: Providing FPGA-specific evaluation IP
From: OutputLogic <evgenist@gmail.com>
Date: Wed, 15 Sep 2010 15:04:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi 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,
Evgeni

Article: 148964
Subject: Re: PSOC3/5
From: rickman <gnuarm@gmail.com>
Date: Wed, 15 Sep 2010 16:13:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Question about OC PCI Cores
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 15 Sep 2010 17:31:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Weng







Article: 148966
Subject: Re: FPGA speech recongintion system
From: backhus <goouse99@googlemail.com>
Date: Thu, 16 Sep 2010 01:31:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
  Eilert

Article: 148967
Subject: Re: Question about OC PCI Cores
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 16 Sep 2010 10:54:23 +0100
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Question about OC PCI Cores
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 16 Sep 2010 07:25:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Weng



Article: 148969
Subject: Re: Question about OC PCI Cores
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 16 Sep 2010 16:59:09 +0100
Links: << >>  << T >>  << A >>
> 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
Subject: Re: FPGA speech recongintion system
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 16 Sep 2010 11:25:08 -0500
Links: << >>  << T >>  << A >>
>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.com

Article: 148971
Subject: New release of HDLmaker
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 16 Sep 2010 21:24:19 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: New release of HDLmaker
From: OutputLogic <evgenist@gmail.com>
Date: Thu, 16 Sep 2010 17:25:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

It'd be very convenient to post the manual in PDF or HTML format
online instead of requiring tool installation.

Thanks,
Evgeni

Article: 148973
Subject: Re: New release of HDLmaker
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 17 Sep 2010 00:40:36 GMT
Links: << >>  << T >>  << A >>
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.htm


Article: 148974
Subject: Re: Preventing timing warnings
From: "agb" <andy.bradford@n_o_s_p_a_m.n_o_s_p_a_m.ultra-ccs.com>
Date: Fri, 17 Sep 2010 02:56:22 -0500
Links: << >>  << T >>  << A >>
>"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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search