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
I would not recommend changing any BGA device unless you have exactly the right equipment and ideally someone with experience to do it. You are highly likely to wreck the board otherwise. I am surprised you can't buy the bigger fitted board in Hungary. We certainly ship our development board products (including the student priced (UAP) packages) there without issue and I doubt the US EAR would cause an issue for Digilent/Xilinx to ship there. John Adair Enterpoint Ltd. www.enterpoint.co.uk On 30 Aug, 14:14, dormanpet...@gmail.com wrote: > Hello! > > I would like to change the FPGA in this board to a bigger one, but I > don't know if it's possible. > I noticed in the datasheet (http://direct.xilinx.com/bvdocs/publications/ds312.pdf > ) that the 500 and 1200 versions are pin compatible (FG320), so my > question would be whether it is enough to simple change it out, or I > have to do something more with it? > (The 4 Mbit platform flash on the board is enough for configuration; > but if I would like to have a S3E1600, I would need 8 Mbit p.f.) > I can see some smd capacitors next to the fpga, quite close... are > they to survive the soldering process, or will I have to buy new ones, > and solder them there?Article: 123701
The Beacon is one way a wakeup from L2 LTSSM state (deep power save). Depends on whether your Phy implementation supports this method or uses the Wake# or even whether the deep power save feature is supported. John Adair Enterpoint Ltd. www.enterpoint.co.uk On 30 Aug, 01:49, vasile <picli...@gmail.com> wrote: > On Aug 29, 5:50 pm, PeteS <axk...@dsl.pipex.com> wrote: > > > > > > > Gabor wrote: > > > On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote: > > >> The spec says all _transmitters_ shall be AC coupled. You just lead the > > >> RX line directly to your component. > > > >> In terms of your a) b) c) options, the answer is therefore c) but only > > >> the TX line(s). > > > >> By the way as far as I remember, there is some Intel doc recommending > > >> placing the cap at 1/3 of the distance from plug to component (i.e. > > >> closer to the plug than to the component). > > > > Also if you're designing a PCIe plug-in card, remember that the signal > > > names on the connector are based on the motherboard. So you need to > > > connect your transmitter to the receive signals (PERP0/PERN0 ...) and > > > your receiver to the transmit signals (PETP0/PETN0 ...). Since the Rx > > > and Tx signals are on the opposite board surface, it is very hard to > > > correct swapped signals using wires! I got bit by this on my first > > > PCIe design. > > > It is very important to make sure your coupling capacitor is large > > enough to handle the 30kHz beacons, so *if* (as I do on occasion) you ac > > couple at _each end of the link_, make sure you used double the > > recommended value of capacitor if it's a short (in the transmission line > > sense) link. > > This is new for me. What do you mean with 30KHz beacon at 3.1Gbps ? > The 0.1uF impedance is large enough for a Ghz signal.- Hide quoted text - > > - Show quoted text -Article: 123702
>>E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes >>from layer 1 to 6 through a via, you should have a bypass cap bewteen power >>and ground near this via. >That's not necessary. There's already so much plane-plane capacitance >that the planes are already equipotential as far as the tiny charge >injected by the signal trace can affect them. >Really, on a board with, say, 3000 vias, are you going to put a bypass >via near every signal via? I've heard of people asking for two! If that was true, would we have a problem crossing plane cuts? My handwave says the plane cut would be C/4 relative to the via case. /2 because the caps for the 2 planes are in series, and another /2 because each cap is only half the size. This sounds like something that should be in (one of) Lee Ritchey's books. Anybody got the page number handy? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123703
>Clearly putting a bypass cap at every via is impractical, and if you re-read >my post, that is not what I suggested. However, I stand by my recommendation >that in places where many nets and/or critial nets change reference planes, >a bypass capacitor nearby is important. Clearly, a single capacitor, perhaps >connected with multiple vias to the planes, can be shared by many signal >vias, as it will have a lot more capacitance than, for example, the planes >can provide. Then I should be able to compute/estimate the value of "nearby" and the size of the cap needed. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123704
On Sun, 02 Sep 2007 09:13:36 -0500, hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >>>E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes >>>from layer 1 to 6 through a via, you should have a bypass cap bewteen power >>>and ground near this via. > >>That's not necessary. There's already so much plane-plane capacitance >>that the planes are already equipotential as far as the tiny charge >>injected by the signal trace can affect them. > >>Really, on a board with, say, 3000 vias, are you going to put a bypass >>via near every signal via? I've heard of people asking for two! > >If that was true, would we have a problem crossing plane cuts? > >My handwave says the plane cut would be C/4 relative to the via >case. /2 because the caps for the 2 planes are in series, and >another /2 because each cap is only half the size. > >This sounds like something that should be in (one of) Lee Ritchey's >books. Anybody got the page number handy? I've experimentally TDR tested plane cuts, and they are generally invisible as long as they are thin as compared to board thickness, or if the ground plane slit is shorted out by an adjacent power plane. All this popular "return current" theorizing is madness. There's so much dielectric shorting a small slit that a signal trace cruises over it and never sees it. Spend s few minutes with a hunk of copperclad, some edge-launch SMAs, an xacto knife, and a 20 GHz TDR scope. It's enlightening. The other fun thing to do is to add some "classicly bad" trace/slit/via structures into spare bits of production boards and TDR them. JohnArticle: 123705
On Sun, 2 Sep 2007 13:15:25 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:oduid31vs6ln11b62visqug6ql7rostl1f@4ax.com... >>> >>>Hi Jon, >>>Yes. But with a caveat. When your signals switch reference layers, make >>>sure >>>there is a path for the reference current. >>> >>>E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal >>>goes >>>from layer 1 to 6 through a via, you should have a bypass cap bewteen >>>power >>>and ground near this via. >> >> >> That's not necessary. There's already so much plane-plane capacitance >> that the planes are already equipotential as far as the tiny charge >> injected by the signal trace can affect them. >> >> Really, on a board with, say, 3000 vias, are you going to put a bypass >> via near every signal via? I've heard of people asking for two! >> >> John >> >Hi John, >I wish that was always the case! There are problems relying solely on the >interplane capacitance. There will be an impedance discontinuity at the via >no matter what, but using solely the interplane capacitance increases this >discontinuity. Clearly the inductance of the signal in this case is higher. >Also, if a bus does the transistion, all the even mode effects add up. >Finally, the high Q of the planes means you are vulnerable to plane >resonances. > >http://www.sigrity.com/papers/epep2000/QC-JZ-EPEP2000-Final.pdf Wow, that's about as incoherent as papers get! >http://www.hottconsultants.com/techtips/pcb-stack-up-6.html Incredible, dangerous nonsense. Absolutely moronic. Quote: "Referencing the Top and Bottom of the Same Plane. Whenever a signal switches layers and references first the top and then the bottom of the same plane we must still ask the question, how does the return current get from the top to the bottom of the plane. Do to the "skin effect" the current cannot flow through the plane, it can only flow on the surface of the plane. This is some sort of joke, right? http://dspace.kaist.ac.kr/bitstream/10203/664/1/effectof.pdf That last one is academic and inconclusive, and the board he uses is not at all realistic. Except in extreme situations, it's safe to assume that parallel planes in a multilayer pcb, bypassed with scattered caps, is an equipotential structure. It's that simple. JohnArticle: 123706
Hi *, on one of our next boards, I'd like to use the Virtex5 feature to have it program itself from an external SPI flash. In that case, the FPGA will provide the SPI clock via the dedicated CCLK pin. What happens to the CCLK pin after configuration is done? Will it go to tristate or still be an output with permanent '0' or '1'? The thing is that I want to use the remaining space in the SPI flash from a microcontroller that is also on the board. The uC then would be the master to the SPI flash after configuration and would have to drive the SPI clock, but this only works if CCLK goes to tristate. There's other ways to do this (like hook up the SPI flash to the uC and have that load the FPGA and such), but the most "elegant" solution would be to just connect flash and uC to the SPI and switch masters on the bus after configuration, if that's possible. Another "problem" is that I also want to have an SPI slave interface inside the FPGA, to set up registers and such via the uC. Since I can't use the CCLK pin as a clock input later on, I'd have to connect the SPI clock from the uC to another pin on the FPGA. So basically I'd have a clock trace that goes from uC to SPI flash and then on the FPGA to the CCLK pin an another clock pin. This line would have to be driven from the FPGA during configuration and from the uC later on. Certainly not optimal from a signal integrity point of view, but has anyone tried this? cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 123707
Hello there! I ported the WebServer example from MicroBlaze Development Kit, Spartan -3E 1600E Edition to spartan 3e starter kit (revD), it seems to work until I want to open a webpage on the embedded webserver... --- I made a new project with the required peripherals, and I added the input buffer and LCD core to the projects, from the .mhs and .mss files I made those modifications which is required (and in the .ucf too). The TestApp_Mem is OK, but when I run the TestApp_Peripheral, It seems that the interrupt controller and the timer not work (with interrupt)... What do you think, what would be the problem with it? (I'm a beginner with not too much experience) I send the MHS and MSS files: # ############################################################################## # Created by Base System Builder Wizard for Xilinx EDK 8.2.02 Build EDK_Im_Sp2.4 # Fri Aug 31 21:24:07 2007 # Target Board: Xilinx Spartan-3E Starter Board Rev D # Family: spartan3e # Device: XC3S500e # Package: FG320 # Speed Grade: -4 # Processor: Microblaze # System clock frequency: 66.666667 MHz # Debug interface: On-Chip HW Debug Module # Data Cache: 8 KB # Instruction Cache: 8 KB # On Chip Memory : 8 KB # Total Off Chip Memory : 80 MB # - FLASH_16Mx8 = 16 MB # - DDR_SDRAM_32Mx16 = 64 MB # ############################################################################## PARAMETER VERSION = 2.1.0 PORT fpga_0_RS232_DCE_RX_pin = fpga_0_RS232_DCE_RX, DIR = I PORT fpga_0_RS232_DCE_TX_pin = fpga_0_RS232_DCE_TX, DIR = O PORT fpga_0_LEDs_8Bit_GPIO_d_out_pin = fpga_0_LEDs_8Bit_GPIO_d_out, DIR = O, VEC = [0:7] PORT fpga_0_DIP_Switches_4Bit_GPIO_in_pin = fpga_0_DIP_Switches_4Bit_GPIO_in, DIR = I, VEC = [0:3] PORT fpga_0_FLASH_16Mx8_Mem_OEN_pin = fpga_0_FLASH_16Mx8_Mem_OEN, DIR = O PORT fpga_0_FLASH_16Mx8_Mem_CEN_pin = fpga_0_FLASH_16Mx8_Mem_CEN, DIR = O, VEC = [0:0] PORT fpga_0_FLASH_16Mx8_Mem_WEN_pin = fpga_0_FLASH_16Mx8_Mem_WEN, DIR = O PORT fpga_0_FLASH_16Mx8_emc_ben_gnd_pin = net_gnd, DIR = O PORT fpga_0_FLASH_16Mx8_Mem_A_pin = fpga_0_FLASH_16Mx8_Mem_A, DIR = O, VEC = [8:31] PORT fpga_0_FLASH_16Mx8_Mem_DQ_pin = fpga_0_FLASH_16Mx8_Mem_DQ, DIR = IO, VEC = [0:7] PORT fpga_0_DDR_SDRAM_32Mx16_DDR_Clk_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_Clk, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_Clkn_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_Clkn, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_Addr_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_Addr, DIR = O, VEC = [0:12] PORT fpga_0_DDR_SDRAM_32Mx16_DDR_BankAddr_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_BankAddr, DIR = O, VEC = [0:1] PORT fpga_0_DDR_SDRAM_32Mx16_DDR_CASn_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_CASn, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_CKE_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_CKE, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_CSn_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_CSn, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_RASn_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_RASn, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_WEn_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_WEn, DIR = O PORT fpga_0_DDR_SDRAM_32Mx16_DDR_DM_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_DM, DIR = O, VEC = [0:1] PORT fpga_0_DDR_SDRAM_32Mx16_DDR_DQS_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_DQS, DIR = IO, VEC = [0:1] PORT fpga_0_DDR_SDRAM_32Mx16_DDR_DQ_pin = fpga_0_DDR_SDRAM_32Mx16_DDR_DQ, DIR = IO, VEC = [0:15] PORT fpga_0_Ethernet_MAC_PHY_tx_clk_pin = fpga_0_Ethernet_MAC_PHY_tx_clk, DIR = I PORT fpga_0_Ethernet_MAC_PHY_rx_clk_pin = fpga_0_Ethernet_MAC_PHY_rx_clk, DIR = I PORT fpga_0_Ethernet_MAC_PHY_crs_pin = fpga_0_Ethernet_MAC_PHY_crs, DIR = I PORT fpga_0_Ethernet_MAC_PHY_dv_pin = fpga_0_Ethernet_MAC_PHY_dv, DIR = I PORT fpga_0_Ethernet_MAC_PHY_rx_data_pin = fpga_0_Ethernet_MAC_PHY_rx_data, DIR = I, VEC = [3:0] PORT fpga_0_Ethernet_MAC_PHY_col_pin = fpga_0_Ethernet_MAC_PHY_col, DIR = I PORT fpga_0_Ethernet_MAC_PHY_rx_er_pin = fpga_0_Ethernet_MAC_PHY_rx_er, DIR = I PORT fpga_0_Ethernet_MAC_PHY_tx_en_pin = fpga_0_Ethernet_MAC_PHY_tx_en, DIR = O PORT fpga_0_Ethernet_MAC_PHY_tx_data_pin = fpga_0_Ethernet_MAC_PHY_tx_data, DIR = O, VEC = [3:0] PORT fpga_0_Ethernet_MAC_PHY_Mii_clk_pin = fpga_0_Ethernet_MAC_PHY_Mii_clk, DIR = IO PORT fpga_0_Ethernet_MAC_PHY_Mii_data_pin = fpga_0_Ethernet_MAC_PHY_Mii_data, DIR = IO PORT fpga_0_DDR_CLK_FB = ddr_feedback_s, DIR = I, SIGIS = CLK, CLK_FREQ = 66666667 PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ = 50000000 PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 1, SIGIS = RST PORT LCD_E_pin = opb_lcd_0_LCD_E, DIR = O PORT LCD_RW_pin = opb_lcd_0_LCD_RW, DIR = O PORT LCD_RS_pin = opb_lcd_0_LCD_RS, DIR = O PORT LCD_DB_pin = opb_lcd_0_LCD_DB, DIR = O, VEC = [3:0] BEGIN microblaze PARAMETER INSTANCE = microblaze_0 PARAMETER HW_VER = 4.00.b PARAMETER C_USE_FPU = 0 PARAMETER C_DEBUG_ENABLED = 1 PARAMETER C_NUMBER_OF_PC_BRK = 2 PARAMETER C_USE_ICACHE = 1 PARAMETER C_CACHE_BYTE_SIZE = 8192 PARAMETER C_USE_DCACHE = 1 PARAMETER C_DCACHE_BYTE_SIZE = 8192 PARAMETER C_ICACHE_USE_FSL = 1 PARAMETER C_DCACHE_USE_FSL = 1 PARAMETER C_ICACHE_BASEADDR = 0x24000000 PARAMETER C_ICACHE_HIGHADDR = 0x27ffffff PARAMETER C_DCACHE_BASEADDR = 0x24000000 PARAMETER C_DCACHE_HIGHADDR = 0x27ffffff BUS_INTERFACE DLMB = dlmb BUS_INTERFACE ILMB = ilmb BUS_INTERFACE DOPB = mb_opb BUS_INTERFACE IOPB = mb_opb BUS_INTERFACE IXCL = ixcl BUS_INTERFACE DXCL = dxcl PORT DBG_CAPTURE = DBG_CAPTURE_s PORT DBG_CLK = DBG_CLK_s PORT DBG_REG_EN = DBG_REG_EN_s PORT DBG_TDI = DBG_TDI_s PORT DBG_TDO = DBG_TDO_s PORT DBG_UPDATE = DBG_UPDATE_s PORT Interrupt = Interrupt PORT RESET = microblaze_rst END BEGIN opb_v20 PARAMETER INSTANCE = mb_opb PARAMETER HW_VER = 1.10.c PARAMETER C_EXT_RESET_HIGH = 1 PORT SYS_Rst = bus_rst_0 PORT OPB_Clk = sys_clk_s END BEGIN opb_mdm PARAMETER INSTANCE = debug_module PARAMETER HW_VER = 2.00.a PARAMETER C_MB_DBG_PORTS = 1 PARAMETER C_USE_UART = 1 PARAMETER C_UART_WIDTH = 8 PARAMETER C_BASEADDR = 0x41400000 PARAMETER C_HIGHADDR = 0x4140ffff BUS_INTERFACE SOPB = mb_opb PORT DBG_CAPTURE_0 = DBG_CAPTURE_s PORT DBG_CLK_0 = DBG_CLK_s PORT DBG_REG_EN_0 = DBG_REG_EN_s PORT DBG_TDI_0 = DBG_TDI_s PORT DBG_TDO_0 = DBG_TDO_s PORT DBG_UPDATE_0 = DBG_UPDATE_s PORT OPB_Rst = periph_rst_0 PORT Debug_SYS_Rst = Debug_SYS_Rst PORT Debug_Rst = Debug_Rst PORT OPB_Clk = sys_clk_s END BEGIN lmb_v10 PARAMETER INSTANCE = ilmb PARAMETER HW_VER = 1.00.a PARAMETER C_EXT_RESET_HIGH = 1 PORT SYS_Rst = bus_rst_1 PORT LMB_Clk = sys_clk_s END BEGIN lmb_v10 PARAMETER INSTANCE = dlmb PARAMETER HW_VER = 1.00.a PARAMETER C_EXT_RESET_HIGH = 1 PORT SYS_Rst = bus_rst_2 PORT LMB_Clk = sys_clk_s END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = dlmb_cntlr PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001fff BUS_INTERFACE SLMB = dlmb BUS_INTERFACE BRAM_PORT = dlmb_port PORT LMB_Rst = periph_rst_1 END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = ilmb_cntlr PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001fff BUS_INTERFACE SLMB = ilmb BUS_INTERFACE BRAM_PORT = ilmb_port PORT LMB_Rst = periph_rst_2 END BEGIN bram_block PARAMETER INSTANCE = lmb_bram PARAMETER HW_VER = 1.00.a BUS_INTERFACE PORTA = ilmb_port BUS_INTERFACE PORTB = dlmb_port PORT BRAM_Rst_A = periph_rst_3 PORT BRAM_Rst_B = periph_rst_4 END BEGIN opb_uartlite PARAMETER INSTANCE = RS232_DCE PARAMETER HW_VER = 1.00.b PARAMETER C_BAUDRATE = 115200 PARAMETER C_DATA_BITS = 8 PARAMETER C_ODD_PARITY = 0 PARAMETER C_USE_PARITY = 0 PARAMETER C_CLK_FREQ = 66666667 PARAMETER C_BASEADDR = 0x40600000 PARAMETER C_HIGHADDR = 0x4060ffff BUS_INTERFACE SOPB = mb_opb PORT Interrupt = RS232_DCE_Interrupt PORT RX = fpga_0_RS232_DCE_RX PORT TX = fpga_0_RS232_DCE_TX PORT OPB_Rst = periph_rst_5 PORT OPB_Clk = sys_clk_s END BEGIN opb_gpio PARAMETER INSTANCE = LEDs_8Bit PARAMETER HW_VER = 3.01.b PARAMETER C_GPIO_WIDTH = 8 PARAMETER C_IS_DUAL = 0 PARAMETER C_IS_BIDIR = 0 PARAMETER C_ALL_INPUTS = 0 PARAMETER C_BASEADDR = 0x40000000 PARAMETER C_HIGHADDR = 0x4000ffff BUS_INTERFACE SOPB = mb_opb PORT GPIO_d_out = fpga_0_LEDs_8Bit_GPIO_d_out PORT OPB_Clk = sys_clk_s PORT OPB_Rst = periph_rst_6 END BEGIN opb_gpio PARAMETER INSTANCE = DIP_Switches_4Bit PARAMETER HW_VER = 3.01.b PARAMETER C_GPIO_WIDTH = 4 PARAMETER C_IS_DUAL = 0 PARAMETER C_IS_BIDIR = 0 PARAMETER C_ALL_INPUTS = 1 PARAMETER C_BASEADDR = 0x40020000 PARAMETER C_HIGHADDR = 0x4002ffff BUS_INTERFACE SOPB = mb_opb PORT GPIO_in = fpga_0_DIP_Switches_4Bit_GPIO_in PORT OPB_Clk = sys_clk_s PORT OPB_Rst = periph_rst_7 END BEGIN opb_emc PARAMETER INSTANCE = FLASH_16Mx8 PARAMETER HW_VER = 2.00.a PARAMETER C_OPB_CLK_PERIOD_PS = 14999 PARAMETER C_NUM_BANKS_MEM = 1 PARAMETER C_MAX_MEM_WIDTH = 8 PARAMETER C_MEM0_WIDTH = 8 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1 PARAMETER C_SYNCH_MEM_0 = 0 PARAMETER C_TCEDV_PS_MEM_0 = 110000 PARAMETER C_TWC_PS_MEM_0 = 110000 PARAMETER C_TAVDV_PS_MEM_0 = 110000 PARAMETER C_TWP_PS_MEM_0 = 70000 PARAMETER C_THZCE_PS_MEM_0 = 35000 PARAMETER C_TLZWE_PS_MEM_0 = 15000 PARAMETER C_MEM0_BASEADDR = 0x22000000 PARAMETER C_MEM0_HIGHADDR = 0x22ffffff BUS_INTERFACE SOPB = mb_opb PORT Mem_A = fpga_0_FLASH_16Mx8_Mem_A_split PORT Mem_DQ = fpga_0_FLASH_16Mx8_Mem_DQ PORT Mem_OEN = fpga_0_FLASH_16Mx8_Mem_OEN PORT Mem_WEN = fpga_0_FLASH_16Mx8_Mem_WEN PORT Mem_CEN = fpga_0_FLASH_16Mx8_Mem_CEN PORT OPB_Clk = sys_clk_s PORT OPB_Rst = periph_rst_8 END BEGIN mch_opb_ddr PARAMETER INSTANCE = DDR_SDRAM_32Mx16 PARAMETER HW_VER = 1.00.c PARAMETER C_INCLUDE_OPB_BURST_SUPPORT = 0 PARAMETER C_MCH_OPB_CLK_PERIOD_PS = 14999 PARAMETER C_REG_DIMM = 0 PARAMETER C_DDR_TMRD = 15000 PARAMETER C_DDR_TWR = 15000 PARAMETER C_DDR_TWTR = 1 PARAMETER C_DDR_TRAS = 40000 PARAMETER C_DDR_TRC = 65000 PARAMETER C_DDR_TRFC = 75000 PARAMETER C_DDR_TRCD = 20000 PARAMETER C_DDR_TRRD = 15000 PARAMETER C_DDR_TRP = 20000 PARAMETER C_DDR_TREFI = 7800000 PARAMETER C_DDR_DWIDTH = 16 PARAMETER C_DDR_AWIDTH = 13 PARAMETER C_DDR_COL_AWIDTH = 10 PARAMETER C_MCH0_ACCESSBUF_DEPTH = 16 PARAMETER C_MCH0_RDDATABUF_DEPTH = 0 PARAMETER C_XCL0_LINESIZE = 4 PARAMETER C_XCL0_WRITEXFER = 0 PARAMETER C_MCH1_ACCESSBUF_DEPTH = 16 PARAMETER C_MCH1_RDDATABUF_DEPTH = 0 PARAMETER C_XCL1_LINESIZE = 4 PARAMETER C_XCL1_WRITEXFER = 1 PARAMETER C_DDR_BANK_AWIDTH = 2 PARAMETER C_DDR_ASYNC_SUPPORT = 1 PARAMETER C_NUM_CLK_PAIRS = 1 PARAMETER C_MEM0_BASEADDR = 0x24000000 PARAMETER C_MEM0_HIGHADDR = 0x27ffffff BUS_INTERFACE SOPB = mb_opb BUS_INTERFACE MCH0 = ixcl BUS_INTERFACE MCH1 = dxcl PORT DDR_Clk = fpga_0_DDR_SDRAM_32Mx16_DDR_Clk PORT DDR_Clkn = fpga_0_DDR_SDRAM_32Mx16_DDR_Clkn PORT DDR_Addr = fpga_0_DDR_SDRAM_32Mx16_DDR_Addr PORT DDR_BankAddr = fpga_0_DDR_SDRAM_32Mx16_DDR_BankAddr PORT DDR_CASn = fpga_0_DDR_SDRAM_32Mx16_DDR_CASn PORT DDR_CKE = fpga_0_DDR_SDRAM_32Mx16_DDR_CKE PORT DDR_CSn = fpga_0_DDR_SDRAM_32Mx16_DDR_CSn PORT DDR_RASn = fpga_0_DDR_SDRAM_32Mx16_DDR_RASn PORT DDR_WEn = fpga_0_DDR_SDRAM_32Mx16_DDR_WEn PORT DDR_DM = fpga_0_DDR_SDRAM_32Mx16_DDR_DM PORT DDR_DQS = fpga_0_DDR_SDRAM_32Mx16_DDR_DQS PORT DDR_DQ = fpga_0_DDR_SDRAM_32Mx16_DDR_DQ PORT Device_Clk90_in = clk_90_s PORT Device_Clk90_in_n = clk_90_n_s PORT Device_Clk = sys_clk_s PORT Device_Clk_n = sys_clk_n_s PORT DDR_Clk90_in = ddr_clk_90_s PORT DDR_Clk90_in_n = ddr_clk_90_n_s PORT MCH_OPB_Rst = periph_rst_9 END BEGIN opb_ethernet PARAMETER INSTANCE = Ethernet_MAC PARAMETER HW_VER = 1.04.a PARAMETER C_DMA_PRESENT = 1 PARAMETER C_IPIF_RDFIFO_DEPTH = 32768 PARAMETER C_IPIF_WRFIFO_DEPTH = 32768 PARAMETER C_OPB_CLK_PERIOD_PS = 14999 PARAMETER C_BASEADDR = 0x40c00000 PARAMETER C_HIGHADDR = 0x40c0ffff BUS_INTERFACE SOPB = mb_opb PORT IP2INTC_Irpt = Ethernet_MAC_IP2INTC_Irpt PORT PHY_tx_clk = fpga_0_Ethernet_MAC_PHY_tx_clk_O PORT PHY_rx_clk = fpga_0_Ethernet_MAC_PHY_rx_clk_O PORT PHY_crs = fpga_0_Ethernet_MAC_PHY_crs PORT PHY_dv = fpga_0_Ethernet_MAC_PHY_dv PORT PHY_rx_data = fpga_0_Ethernet_MAC_PHY_rx_data PORT PHY_col = fpga_0_Ethernet_MAC_PHY_col PORT PHY_rx_er = fpga_0_Ethernet_MAC_PHY_rx_er PORT PHY_tx_en = fpga_0_Ethernet_MAC_PHY_tx_en PORT PHY_tx_data = fpga_0_Ethernet_MAC_PHY_tx_data PORT PHY_Mii_clk = fpga_0_Ethernet_MAC_PHY_Mii_clk PORT PHY_Mii_data = fpga_0_Ethernet_MAC_PHY_Mii_data PORT OPB_Clk = sys_clk_s PORT OPB_Rst = periph_rst_10 END BEGIN opb_timer PARAMETER INSTANCE = opb_timer_1 PARAMETER HW_VER = 1.00.b PARAMETER C_COUNT_WIDTH = 32 PARAMETER C_ONE_TIMER_ONLY = 1 PARAMETER C_BASEADDR = 0x41c00000 PARAMETER C_HIGHADDR = 0x41c0ffff BUS_INTERFACE SOPB = mb_opb PORT Interrupt = opb_timer_1_Interrupt PORT OPB_Clk = sys_clk_s PORT OPB_Rst = periph_rst_12 END BEGIN opb_intc PARAMETER INSTANCE = opb_intc_0 PARAMETER HW_VER = 1.00.c PARAMETER C_BASEADDR = 0x41200000 PARAMETER C_HIGHADDR = 0x4120ffff PARAMETER C_NUM_INTR_INPUTS = 2 BUS_INTERFACE SOPB = mb_opb PORT Irq = Interrupt PORT Intr = RS232_DCE_Interrupt & Ethernet_MAC_IP2INTC_Irpt & opb_timer_1_Interrupt PORT OPB_Rst = periph_rst_13 END BEGIN util_bus_split PARAMETER INSTANCE = FLASH_16Mx8_util_bus_split_1 PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE_IN = 32 PARAMETER C_LEFT_POS = 0 PARAMETER C_SPLIT = 8 PORT Sig = fpga_0_FLASH_16Mx8_Mem_A_split PORT Out2 = fpga_0_FLASH_16Mx8_Mem_A END BEGIN util_vector_logic PARAMETER INSTANCE = sysclk_inv PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE = 1 PARAMETER C_OPERATION = not PORT Op1 = sys_clk_s PORT Res = sys_clk_n_s END BEGIN util_vector_logic PARAMETER INSTANCE = clk90_inv PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE = 1 PARAMETER C_OPERATION = not PORT Op1 = clk_90_s PORT Res = clk_90_n_s END BEGIN util_vector_logic PARAMETER INSTANCE = ddr_clk90_inv PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE = 1 PARAMETER C_OPERATION = not PORT Op1 = ddr_clk_90_s PORT Res = ddr_clk_90_n_s END BEGIN dcm_module PARAMETER INSTANCE = dcm_0 PARAMETER HW_VER = 1.00.a PARAMETER C_CLK0_BUF = TRUE PARAMETER C_CLKFX_BUF = TRUE PARAMETER C_CLKFX_DIVIDE = 3 PARAMETER C_CLKFX_MULTIPLY = 4 PARAMETER C_CLKIN_PERIOD = 20.000000 PARAMETER C_CLK_FEEDBACK = 1X PARAMETER C_EXT_RESET_HIGH = 1 PORT CLKIN = dcm_clk_s PORT CLKFX = sys_clk_s PORT CLK0 = dcm_0_FB PORT CLKFB = dcm_0_FB PORT RST = net_gnd PORT LOCKED = dcm_0_lock END BEGIN dcm_module PARAMETER INSTANCE = dcm_1 PARAMETER HW_VER = 1.00.a PARAMETER C_CLK0_BUF = TRUE PARAMETER C_CLK90_BUF = TRUE PARAMETER C_CLKIN_PERIOD = 15.000000 PARAMETER C_CLK_FEEDBACK = 1X PARAMETER C_EXT_RESET_HIGH = 0 PORT CLKIN = sys_clk_s PORT CLK90 = clk_90_s PORT CLK0 = dcm_1_FB PORT CLKFB = dcm_1_FB PORT RST = dcm_0_lock PORT LOCKED = dcm_1_lock END BEGIN dcm_module PARAMETER INSTANCE = dcm_2 PARAMETER HW_VER = 1.00.a PARAMETER C_CLK0_BUF = TRUE PARAMETER C_CLK90_BUF = TRUE PARAMETER C_CLKIN_PERIOD = 15.000000 PARAMETER C_CLK_FEEDBACK = 1X PARAMETER C_EXT_RESET_HIGH = 0 PORT CLKIN = ddr_feedback_s PORT CLK90 = ddr_clk_90_s PORT CLK0 = dcm_2_FB PORT CLKFB = dcm_2_FB PORT RST = dcm_1_lock PORT LOCKED = dcm_2_lock END BEGIN proc_sys_reset PARAMETER INSTANCE = proc_sys_reset_0 PARAMETER HW_VER = 1.00.a PARAMETER C_EXT_RESET_HIGH = 1 PARAMETER C_NUM_BUS_RST = 3 PARAMETER C_NUM_PERP_RST = 14 PORT Dcm_locked = dcm_2_lock PORT Bus_Struct_Reset = bus_rst_0 & bus_rst_1 & bus_rst_2 PORT Peripheral_Reset = periph_rst_0 & periph_rst_1 & periph_rst_2 & periph_rst_3 & periph_rst_4 & periph_rst_5 & periph_rst_6 & periph_rst_7 & periph_rst_8 & periph_rst_9 & periph_rst_10 & periph_rst_11 & periph_rst_12 & periph_rst_13 PORT Slowest_sync_clk = sys_clk_s PORT Ext_Reset_In = sys_rst_s PORT Aux_Reset_In = net_gnd PORT Core_Reset_Req = Debug_Rst PORT Chip_Reset_Req = net_gnd PORT System_Reset_Req = Debug_SYS_Rst PORT Rstc405resetcore = microblaze_rst END BEGIN input_buf PARAMETER INSTANCE = in_buf0 PARAMETER HW_VER = 1.00.a PARAMETER DWIDTH = 2 PORT I = fpga_0_Ethernet_MAC_PHY_tx_clk & fpga_0_Ethernet_MAC_PHY_rx_clk PORT O = fpga_0_Ethernet_MAC_PHY_tx_clk_O & fpga_0_Ethernet_MAC_PHY_rx_clk_O END BEGIN opb_lcd PARAMETER INSTANCE = char_lcd PARAMETER HW_VER = 1.00.c PARAMETER C_BASEADDR = 0x73a00000 PARAMETER C_HIGHADDR = 0x73a0ffff BUS_INTERFACE SOPB = mb_opb PORT LCD_E = opb_lcd_0_LCD_E PORT LCD_RW = opb_lcd_0_LCD_RW PORT LCD_RS = opb_lcd_0_LCD_RS PORT LCD_DB = opb_lcd_0_LCD_DB PORT OPB_Clk = sys_clk_s PORT OPB_Rst = periph_rst_11 END ---------------------------------------------------------------------------------------------------------------------------------- system.mss: PARAMETER VERSION = 2.2.0 BEGIN OS PARAMETER OS_NAME = xilkernel PARAMETER OS_VER = 3.00.a PARAMETER PROC_INSTANCE = microblaze_0 PARAMETER sysintc_spec = opb_intc_0 PARAMETER stdout = RS232_DCE PARAMETER stdin = RS232_DCE PARAMETER config_debug_support = true PARAMETER config_sema = true PARAMETER max_sem_waitq = 100 PARAMETER max_sem = 25 PARAMETER config_time = true PARAMETER max_tmrs = 100 PARAMETER systmr_freq = 66666667 PARAMETER systmr_dev = opb_timer_1 PARAMETER max_readyq = 100 PARAMETER pthread_stack_size = 16384 PARAMETER max_pthreads = 100 PARAMETER static_pthread_table = ((serverThread,1)) END BEGIN PROCESSOR PARAMETER DRIVER_NAME = cpu PARAMETER DRIVER_VER = 1.01.a PARAMETER HW_INSTANCE = microblaze_0 PARAMETER COMPILER = mb-gcc PARAMETER ARCHIVER = mb-ar PARAMETER XMDSTUB_PERIPHERAL = debug_module PARAMETER CORE_CLOCK_FREQ_HZ = 50000000 END BEGIN DRIVER PARAMETER DRIVER_NAME = opbarb PARAMETER DRIVER_VER = 1.02.a PARAMETER HW_INSTANCE = mb_opb END BEGIN DRIVER PARAMETER DRIVER_NAME = uartlite PARAMETER DRIVER_VER = 1.01.a PARAMETER HW_INSTANCE = debug_module END BEGIN DRIVER PARAMETER DRIVER_NAME = bram PARAMETER DRIVER_VER = 1.00.a PARAMETER HW_INSTANCE = dlmb_cntlr END BEGIN DRIVER PARAMETER DRIVER_NAME = bram PARAMETER DRIVER_VER = 1.00.a PARAMETER HW_INSTANCE = ilmb_cntlr END BEGIN DRIVER PARAMETER DRIVER_NAME = uartlite PARAMETER DRIVER_VER = 1.01.a PARAMETER HW_INSTANCE = RS232_DCE END BEGIN DRIVER PARAMETER DRIVER_NAME = gpio PARAMETER DRIVER_VER = 2.01.a PARAMETER HW_INSTANCE = LEDs_8Bit END BEGIN DRIVER PARAMETER DRIVER_NAME = gpio PARAMETER DRIVER_VER = 2.01.a PARAMETER HW_INSTANCE = DIP_Switches_4Bit END BEGIN DRIVER PARAMETER DRIVER_NAME = emc PARAMETER DRIVER_VER = 2.00.a PARAMETER HW_INSTANCE = FLASH_16Mx8 END BEGIN DRIVER PARAMETER DRIVER_NAME = sdram PARAMETER DRIVER_VER = 1.00.a PARAMETER HW_INSTANCE = DDR_SDRAM_32Mx16 END BEGIN DRIVER PARAMETER DRIVER_NAME = emac PARAMETER DRIVER_VER = 1.01.a PARAMETER HW_INSTANCE = Ethernet_MAC END BEGIN DRIVER PARAMETER DRIVER_NAME = tmrctr PARAMETER DRIVER_VER = 1.00.b PARAMETER HW_INSTANCE = opb_timer_1 END BEGIN DRIVER PARAMETER DRIVER_NAME = intc PARAMETER DRIVER_VER = 1.00.c PARAMETER HW_INSTANCE = opb_intc_0 END BEGIN DRIVER PARAMETER DRIVER_NAME = generic PARAMETER DRIVER_VER = 1.00.a PARAMETER HW_INSTANCE = in_buf0 END BEGIN DRIVER PARAMETER DRIVER_NAME = generic PARAMETER DRIVER_VER = 1.00.a PARAMETER HW_INSTANCE = char_lcd END BEGIN LIBRARY PARAMETER LIBRARY_NAME = xilmfs PARAMETER LIBRARY_VER = 1.00.a PARAMETER PROC_INSTANCE = microblaze_0 PARAMETER need_utils = true PARAMETER init_type = MFSINIT_IMAGE PARAMETER base_address = 0x25000000 PARAMETER numbytes = 319200 END BEGIN LIBRARY PARAMETER LIBRARY_NAME = lwip PARAMETER LIBRARY_VER = 2.00.a PARAMETER PROC_INSTANCE = microblaze_0 PARAMETER api_mode = SOCKETS_API PARAMETER memp_num_sys_timeout = 5 PARAMETER memp_num_tcp_seg = 510 PARAMETER mem_size = 65538 PARAMETER emac_instances = ((Ethernet_MAC, 0x01,0x02,0x03,0x04,0x05,0x06)) ENDArticle: 123708
On Tue, 28 Aug 2007 14:26:59 -0000, "comp.arch.fpga" <ksulimma@googlemail.com> wrote: >> E.g. Jonathan Bromley posted on 2007 March 5th: >Hmm. I just have to counter that post here. > >> [..] The majority of >> hardware platforms do not offer reliable power-up >> initialisation of internal state. >True. But the vast majority of design starts are on platforms that do >support it. I have spoken with forked tongue.... You may recall that a while ago I had a dispute about this with Rob Dekker of Verific (a software company whose prime product is an HDL front-end, used by many vendors of synthesis, formal and linting tools): see the thread Coding style, wait statement, sensitivity list and synthesis. in comp.lang.vhdl around January 2006. I tried there to argue that synthesis front-ends should support any construct that maps to physically realisable hardware, and the back-end (mapper) should error-out if the specific target does not support the necessary features. I still think I was right, but I don't think my arguments prevailed. So I have reverted to my standard, conservative position that synthesis users should restrict themselves to a lowest-common-denominator style. I make a few exceptions: for example, there are still synthesis tools around (at least, there were the last time I checked) that won't tolerate Verilog with a mixture of blocking and nonblocking assignments, thereby making it impossible to emulate VHDL variables in Verilog. That is so laughably stupid that I'm prepared to tell people not to use such tools. But support for initialization is still restricted to a small subset of the available tools, so I can't reasonably recommend it except to Xilinx- or Altera-specific users. My conservative position must not be taken as an argument that we shouldn't try to move forward. Basically I agree with everything Kolja has said; it's just that I am obliged to help people to make the best of what they have today - and sometimes those people need to write highly portable code. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 123709
Sean, USR_ACCESS_VIRTEX5 in http://direct.xilinx.com/bvdocs/userguides/ug191.pdf page 92: "The STARTUP_VIRTEX5 block has inputs that allow the user to take over the CCLK and DONE pins after the EOS (End-Of-Startup) signal is asserted." Not sure, but this sounds like what you need? AustinArticle: 123710
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:shbmd3pmpmo6sfkqj46lv0ls2dhssq2di0@4ax.com... > On Tue, 28 Aug 2007 14:26:59 -0000, "comp.arch.fpga" > <ksulimma@googlemail.com> wrote: > > >>> E.g. Jonathan Bromley posted on 2007 March 5th: > in comp.lang.vhdl around January 2006. I tried there to > argue that synthesis front-ends should support any construct > that maps to physically realisable hardware, and the back-end > (mapper) should error-out if the specific target does not > support the necessary features. I still think I was right, I don't recall the thread but I totally agree with you. > but I don't think my arguments prevailed. So I have reverted > to my standard, conservative position that synthesis users > should restrict themselves to a lowest-common-denominator > style. For whatever tools that you have that meet the following two tests, did you open a service request? - Tool claims compliance to VHDL standard - Tool does not error (or at least warning) about ignoring the initial value assignment If you did not, then (shame on you) and why not? The way to get tool vendors to change their tools is to hit them directly with a service request on their tool. It's not always successful, but I've found that many times it is in this type of example since they have been called on a particular area of non-compliance on a tool that they say is compliant to a particular standard. > My conservative position must not be taken as an argument > that we shouldn't try to move forward. Basically I agree > with everything Kolja has said; it's just that I am obliged > to help people to make the best of what they have today - > and sometimes those people need to write highly portable code. And publicize against the tools that don't support the language. KJArticle: 123711
I'd like to try out some ideas and would appreciate some guidance. Would a 200k-gate FPGA be enough for a simple or complex 8-bit CPU design? I have this Digilent product: http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS but being totally new to hardware design I have some questions: 1. What language would be suitable - VHDL or Verilog? Or are there others? 2. What description style would be appropriate? Or can I break the design into modules, initially make each module with a high level description and rewrite it at a lower level later as needed?Article: 123712
On 2 Sep, 23:40, James Harris <james.harri...@googlemail.com> wrote: > I'd like to try out some ideas and would appreciate some guidance. > Would a 200k-gate FPGA be enough for a simple or complex 8-bit CPU > design? I have this Digilent product: > > http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS > > but being totally new to hardware design I have some questions: > > 1. What language would be suitable - VHDL or Verilog? Or are there > others? > > 2. What description style would be appropriate? Or can I break the > design into modules, initially make each module with a high level > description and rewrite it at a lower level later as needed? Should have said that part of the design is a large crossbar switch. It may be relevant to the number of gates and/or the design style. -- TIA, JamesArticle: 123713
On 2007-09-02, James Harris <james.harris.1@googlemail.com> wrote: > On 2 Sep, 23:40, James Harris <james.harri...@googlemail.com> wrote: >> I'd like to try out some ideas and would appreciate some guidance. >> Would a 200k-gate FPGA be enough for a simple or complex 8-bit CPU >> design? I have this Digilent product: >> >> http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS >> >> but being totally new to hardware design I have some questions: >> >> 1. What language would be suitable - VHDL or Verilog? Or are there >> others? >> >> 2. What description style would be appropriate? Or can I break the >> design into modules, initially make each module with a high level >> description and rewrite it at a lower level later as needed? > > Should have said that part of the design is a large crossbar switch. > It may be relevant to the number of gates and/or the design style. How large is "large"? But it should be fairly simply to calculate the size of a crossbar switch. Assuming the switch is implemented using muxes: A 2-to-1 mux uses 1 LUT A 4-to-1 mux uses 2 LUTs An 8-to-1 mux uses 4 LUTs A 16-to-1 mux uses 8 LUTs (and so on) Multiply this with the number of ports and the width of each port to get a rough total LUT cost. (Ignoring the cost of the arbiter or other configuration logic for the crossbar.) An XC3S200 has 3840 LUTs if I calculate correctly. So an 8x8 crossbar with 8 bit wide ports should fit fairly comfortable whereas for example a 16x16 crossbar of width 16 will consume half the FPGA. How often do you need to reconfigure the inputs/outputs of the crossbar? If it is not very often, perhaps you could serially load configuration data into SRL16 elements to reduce the number of required LUTs. What kind of bitrate do you need through the crossbar? Perhaps you could use a time-multiplexed bus instead? /AndreasArticle: 123714
On Sun, 02 Sep 2007 17:58:27 +0200, Sean Durkin <news_sep07@durkin.de> wrote: >Hi *, > >on one of our next boards, I'd like to use the Virtex5 feature to have >it program itself from an external SPI flash. In that case, the FPGA >will provide the SPI clock via the dedicated CCLK pin. > >What happens to the CCLK pin after configuration is done? Will it go to >tristate or still be an output with permanent '0' or '1'? > >The thing is that I want to use the remaining space in the SPI flash >from a microcontroller that is also on the board. The uC then would be >the master to the SPI flash after configuration and would have to drive >the SPI clock, but this only works if CCLK goes to tristate. > >There's other ways to do this (like hook up the SPI flash to the uC and >have that load the FPGA and such), but the most "elegant" solution would >be to just connect flash and uC to the SPI and switch masters on the bus >after configuration, if that's possible. > >Another "problem" is that I also want to have an SPI slave interface >inside the FPGA, to set up registers and such via the uC. Since I can't >use the CCLK pin as a clock input later on, I'd have to connect the SPI >clock from the uC to another pin on the FPGA. So basically I'd have a >clock trace that goes from uC to SPI flash and then on the FPGA to the >CCLK pin an another clock pin. This line would have to be driven from >the FPGA during configuration and from the uC later on. > >Certainly not optimal from a signal integrity point of view, but has >anyone tried this? That all sounds reasonable, but be very careful about signal integrity on that big, possibly stubby, clock net, especially where it becomes "another clock pin." Any mistermination plateau, or a slow (a few ns slow!) or ringy clock with a little crosstalk, can make trouble. Unless the situation is perfect, we put a tiny-logic schmitt adjacent to any FPGA clock that we're driving, including CCLK if the fpga is in slave serial mode. JohnArticle: 123715
Hi, I am learning tcl in Xilinx 9.1. For the learning example watchvhd, the following error occurs. ERROR:Portability:90 - Command line error: Switch "-intstyle" is excluded or already used. What's wrong with it? But for my slow laptop, which installed a 8.2 version ISE, it can pass the implementation. Could you help me out? Thanks in advance. # open the project and set project-level properties project open watchvhd.ise project set family Virtex2P project set device xc2vp2 project set package fg256 project set speed -7 # add all the source HDLs and ucf #xfile add stopwatch.vhd statmatch.vhd cnt60.vhd dcm1.vhd decode.vhd #xfile add tenths.vhd hex2led #xfile add watchvhd.ucf # define all partitions #partition new /stopwatch/MACHINE #partition new /stopwatch/Inst_dcm1 #partition new /stopwatch/XCOUNTER #partition new /stopwatch/decoder #partition new /stopwatch/sixty #partition new /stopwatch/lsbled #partition new /stopwatch/msbled # get partition properties set props [partition properties] puts "Partition Properties : $props" # get top set top [project get top] # get project properties available set props2 [project properties] puts "Project Properties for top-level module $top $props2" # inspect the current value for the following batch application options #set map_guide_mode [project get "MAP Guide Mode"] #puts "MAP Guide Mode = $map_guide_mode" #set par_guide_mode [project get "PAR Guide Mode"] #puts "PAR Guide Mode = $par_guide_mode" # set batch application options : # 1. set synthesis optimization goal to speed # 2. ignore any LOCs in ngdbuild # 3. perform timing-driven packing # 4. use the highest par effort level # 5. set the par extra effort level # 6. pass "-instyle xflow" to the par command-line # 7. generate a verbose report from trce # 8. create the IEEE 1532 file during bitgen project set "Optimization Goal" "Speed" #project set "Hierarchy Separator" / project set "Use LOC Constraints" "false" project set "Perform Timing-Driven Packing and Placement" "TRUE" project set "Place & Route Effort Level (Overall)" "High" project set "Extra Effort (Highest PAR level only)" "Continue on Impossible" project set "Other Place & Route Command Line Options" "-intstyle silent" project set "Report Type" "Verbose Report" project set "Create IEEE 1532 Configuration File" "TRUE" # run the entire xst-to-trce flow process run "Implement Design" # close project project closeArticle: 123716
Hi. It is possible to have a format of .pof/.sof files from Altera, thus, to decompile some ready projects and try to make our own, omitting Altera software tools?Article: 123717
I use the Nios II system to achieve my design. I have define a data bus from the outside of the FPGA, I use a 8-bits PIO ip to connect the signal and the FPGA. I want to achieve the following aim: when the outside signals changes, Nios generates a IRQ to CPU, and I can insert my instructions. Please tell me , how can I do it ?Article: 123718
hezhikuan2007@gmail.com wrote: > I want to achieve the following aim: when the outside signals > changes, Nios generates a IRQ to CPU, and I can insert my > instructions. Read Chapter 13 of the QUartus II Handbook Volume 5. (aka n2cpu_nii51007-2.pdf) Or if that's not quite what you need, create a (trivial) SOPC component that generates an interrupt when you need to. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 123719
Hi, I updated the GTKWave for Win32 port I am maintaining. It's at 3.1.0 which supports reload now. http://www.dspia.com/gtkwave.htmlArticle: 123720
Thank you very much! You give me a lot!Article: 123721
On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> Jim,
>
> On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:
>
> |------------------------------------------------------------------------=
--=AD|
> |"Weng, =
|
> |[..] =
|
> | =
|
> |[..] =
|
> | =
|
> |I noted that in your code you mixed orif mixed with elsif (copied below)=
, |
> |was this intentional? One hand, these could convey exactly what I want =
|
> |(because there are many cases like this), OTOH, it could be a mistake. =
|
> |Hence the intent is ambiguous and during a design review, one would have=
|
> |to pay particular attention to this and ask questions about your intent =
|
> |and its validation. A copy of your code is below. =
|
> | =
|
> |If(E0 =3D '1') then =
|
> |State_A <=3D E0_S; =
|
> |Orif(E1 =3D '1') then =
|
> |State_A <=3D E_S; =
|
> |Orif(E2 =3D '1') then =
|
> |State_A <=3D E2_S; =
|
> |elsIf(E3 =3D '1') then =
|
> |State_A <=3D E3_S; =
|
> |Orif(E4 =3D '1') then =
|
> |State_A <=3D E4_S; =
|
> |Orif(E5 =3D '1') then =
|
> |State_A <=3D E5_S; =
|
> |elsIf(E6 =3D '1') then =
|
> |" =
|
> |------------------------------------------------------------------------=
--=AD|
>
> Yes,
>
> Weng really did intend to have both orif branches and elsif branches
> in a single if statement (seenews:1188325844.164564.136940@z24g2000prh.go=
oglegroups.com
> ). I think the intention would be clearer with different
> indentation. E.g.
> If(E0 =3D '1') then
> State_A <=3D E0_S;
> Orif(E1 =3D '1') then
> State_A <=3D E_S;
> Orif(E2 =3D '1') then
> State_A <=3D E2_S;
>
> elsIf(E3 =3D '1') then
> State_A <=3D E3_S;
> Orif(E4 =3D '1') then
> State_A <=3D E4_S;
> Orif(E5 =3D '1') then
> State_A <=3D E5_S;
> elsIf(E6 =3D '1') then
> --...
>
> |------------------------------------------------------------------------=
--=AD|
> |"[..] =
|
> | =
|
> |[..] The danger in adding new keywords is that they may =
|
> |conflict with a name (signal, ...) already used in someone's design =
|
> |and cause an old design to be a syntax error in the new language =
|
> |revision. This generally does not please people and means they =
|
> |have to add special handling for the file (compile flags). =
|
> | =
|
> |[..]" =
|
> |------------------------------------------------------------------------=
--=AD|
>
> A newly introduced reserved word would be guaranteed to not conflict
> with old code by not being possible to misinterpret as a basic
> identifier (basic_identifier ::=3D letter { [ underline ]
> letter_or_digit), e.g. by starting with an underline or by containing
> a percentage sign.
>
> Best regards,
> Colin Paul
Hi Colin,
I have difficulties to understand following segment you are talking
about the name conflicts.
|[..] The danger in adding new keywords is that they
may |
|conflict with a name (signal, ...) already used in someone's
design |
|and cause an old design to be a syntax error in the new
language |
|revision. This generally does not please people and means
they |
|have to add special handling for the file (compile
flags). |
|
|
|
[=2E.]"
|
|--------------------------------------------------------------------------=
=AD|
A newly introduced reserved word would be guaranteed to not conflict
with old code by not being possible to misinterpret as a basic
identifier (basic_identifier ::=3D letter { [ underline ]
letter_or_digit), e.g. by starting with an underline or by containing
a percentage sign.
I would like to know what Jim's name conflicting mechanism is.
1=2E Here I have an old file using the following statements:
assertion zero_one_hot(); -- the function was defined in an old file
Here I have another new file using the following statements:
assertion zero_one_hot(); -- try to refer to Jim's function.
Those two above files must be compiled together using 2006 version.
What happens?
No name conflicting?
2=2E Here is orif name conflicting.
Here I have an old file containing orif as a signal and has the
following statements.
Signal orif : std_logic;
.=2E.
If(orif =3D ...) then
Here I have an new file containing orif as a signal and has the
following statements.
Signal orif : std_logic;
.=2E.
If(orif =3D ...) then
When the old file is compiled by new 2006 version, what would happen
with above two statements? When the new file is compiled by new 2006
version, what would happen with above two statements?
How does 2006 version know that what it deals with is an old file or a
new file with your method?
Jim, here is my solution to your naming conflicting problem.
VERY SIMPLE AND COMPLETE !!!
If a 2006 version compiler uses file date to distinguish old file or
new file by reading their file generation year, before 2007 and after
2007, there is no any trouble to deal with new or old files and both
files can safely be compiled without error.
For 2006 compiler do the following things:
1=2E Read vhd file;
2=2E Read their last update date and get year number;
3=2E When year number <=3D 2006, orif is cleared in reserved word list;
When year number >=3D 2007, oris is in reserved word list.
4=2E If more accurate date is needed, it can add month and date to the
check list.
It doesn't need to add any extra characters before orif. I think
Verilog had used the same method as I suggested and it would guarantee
that there is no naming conflict.
Any comments?
Thank you.
Weng
Article: 123722> It is possible to have a format of .pof/.sof files from Altera, thus, > to decompile some ready projects and try to make our own, omitting > Altera software tools? No, we do not give out the format of the POF/SOF. Sorry, Paul Leventis Altera Corp.Article: 123723
Jim and Colin, Here is a more flexible method that can avoid orif name conflicting problem at any situations. For 2006 compiler do the following things: 1. When being installed, VHDL 2006 compiler pops up a window to allow clients to set a date after which all VHDL files will be compiled with orif feature, then writes the date into VHDL initial file with item: 2006_orif_Starting_Date = 09/02/2007; 2. Read vhd file; 3. Read its last update date; 4. If the file date is after the date contained in 2006_orif_Starting_Date equation of VHDL.ini, orif is in reserved word list, otherwise orif is cleared in reserved word list. All trouble happens only at installation. If it is found later there is need to change the effective date, users can modify the date contained in 2006_orif_Starting_Date equation of the initial file. Thank you. WengArticle: 123724
Hi, While low-power FPGAs are extremely interesting and there definetely is market opportunity there, it's not the most convincing start to go and ask example applications from the newsgroups... Having said that, you can always start by beating AudioDE http://www.arm.com/products/DataEngines/audioDE.html -Doug On Aug 30, 9:21 pm, siliconbluetechnol...@yahoo.com wrote: > Hello, > > Silicon Blue Technologies is an FPGA startup located in Sunnyvale CA. > The FPGA product it is developing has ultra low power consumption and > is targeted to low power applications. > > The company is seeking some commercial designs in the form of Verilog > and/or VHDL designs to test its software and FPGA architecture. > > Please provide your input if you are interested in the product or have > testcases which can be useful to test both FPGA hardware and software > capabilities. > > Thank you. > > Silicon Blue Technologieshttp://www.siliconbluetech.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