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
Hi > > Not sure what you mean by "the FPGA, not the Flash yet". Can you explain? > Does this imply that we can now use the $99 board that Xilinx is selling > with Linux now? What limitations are implied by "not the Flash yet"? > The flash is the little PROM on board, the non-volatile memory. The FPGA need to reload its config each time it's powered. It can download it's config from a little flash on the board (so that the board is autonomous) and this PROM is on the JTAG chain too, but you can't program it with this application yet. Personnaly, I'm now doing all my Xilinx work under Linux. I use wine for the WebPack. That's sometimes a little slow when "compiling" but that's OK. And this prog to program the bitstream. The only thing I can't do is program the PROM. SylvainArticle: 72326
Hi All, I am designing a system which has both hardware and software parts. I want to make some computations in the hardware and then sample the results in the software running on PowerPC. Did anyone do something similar? Whats the best and the easiest way to do this? Thanks, RamtilakArticle: 72327
Sean Durkin <smd@despammed.com> wrote: > you can reconfigure the FPGA with simple memory writes. But in real > life, it's so complicated and there's so many restrictions and bugs in > the tools that in most cases it's useless and not worth the trouble. > It's a bit easier if you use a MicroBlaze instead of the PowerPC, since > you can put the MicroBlaze pretty much everywhere you want, which makes > the whole process a lot easier. Uh? It's not _that_ bad, isn't it? As for the tools being buggy, if your talking about modular design flow, then probably everybody agrees, but otherwise you shuold be fine. At least the ICAP is easier to handle than the SelectMAP (see my other post :( ). Regarding the placement of the MicroBlaze, it really takes up so much area that I wouldn't consider it _better_ than the PPC. In fact with the PPC, you only loose the couple columns associated with that PPC (and you can area-constrain the ppc-icap-interface to those same columns), which should be less than the number of columns required for a Microblaze in the smaller devices (up to 2vp20 I would guess). Anyway, if you have any specific problems with the ICAP, please ask :) regards, -gArticle: 72328
Hello, I've been unsuccessfully trying to use the SDRAM on my MJL Cyclone dev kit. I've tried the example (not very well documented) sold with the dev kit, and tried the Altera IP Sdram controller. The way i do it : I connect the sdram controller to the sdram and use a small test module to check it reads and writes. I start with the initialisation sequence of the ram (nop for 100µs then load register), i write at the adress 0...00 and then at adress 0..01, read alternatively each adress with a pause and print the output on a digit. At best i have something funny on the digit, which is most of the time not what i want, at worst i have the digit blank. On the Altera IP, i use the built it pll on clk1 to drive the sdram (since it seems from the specsheets that the output of pll1 is connected to the sdram clk) and either the clk1 or another clk to feed the whole. (i tried at 100 and 33 MHz). With the MJL Cyclone dev kit i use the pll1 to fee the sdram and the sdram controller. I've tried to simulate (I use Quartus 4.1) and it seems that the simulation is completly out of its head. I have states transitions BEFORE the signal driving it actually arrives. Are the simulation reliable with the plls ? Do you please have some idea of what i am doing wrong ? Thank you very much Nick CharlesArticle: 72329
Sylvain Munaut wrote: > Hi > >> >> Not sure what you mean by "the FPGA, not the Flash yet". Can you >> explain? >> Does this imply that we can now use the $99 board that Xilinx is >> selling with Linux now? What limitations are implied by "not the >> Flash yet"? >> > > The flash is the little PROM on board, the non-volatile memory. The FPGA > need to reload its config each time it's powered. It can download it's > config from a little flash on the board (so that the board is > autonomous) and this PROM is on the JTAG chain too, but you can't > program it with this application yet. > > > Personnaly, I'm now doing all my Xilinx work under Linux. > > I use wine for the WebPack. That's sometimes a little slow when > "compiling" but that's OK. And this prog to program the bitstream. > The only thing I can't do is program the PROM. > In due course I'll be working on programming the PROM. At the moment I'm struggling to find a datasheet on the XCF02S PROM that gives the programming algorithm. Even without the datasheet I will not give up. Can anyone tell me where I can find the programming algorithm for the XCF02S PROM? Thanks AndrewArticle: 72330
Ramtilak, Look at the UltraController Application Note which has a prebuilt PowerPC system and 32-bit GPIO interface to fabric to bring data into and onto the FPGA fabric from software running on the PowerPC. More information on this design can be found at: http://www.xilinx.com/ultracontroller. Shalin- Ramtilak wrote: > Hi All, > > I am designing a system which has both hardware and software parts. I > want to make some computations in the hardware and then sample the > results in the software running on PowerPC. Did anyone do something > similar? Whats the best and the easiest way to do this? > > Thanks, > RamtilakArticle: 72331
Hi, I have read a few articles about SSO and the fact that ground bounce may occur and therefore the ground reference of the chip is different from the ground of the board the chip is on. I was wondering if a ground bounce problem on one bank of an FPGA could create issues on other interfaces located on other banks of the FPGA ? I also understood that SSO guidelines for Xilinx FPGAs were given considering a perfect decoupling system. What is the impact of decoupling on the fact that many outputs switch at the same time and that the return current is too important on one ground pin involving ground bounce ? Thanks, JFArticle: 72332
Andrew Rogers wrote: > Sylvain Munaut wrote: > >> Hi >> >>> >>> Not sure what you mean by "the FPGA, not the Flash yet". Can you >>> explain? >>> Does this imply that we can now use the $99 board that Xilinx is >>> selling with Linux now? What limitations are implied by "not the >>> Flash yet"? >>> >> >> The flash is the little PROM on board, the non-volatile memory. The >> FPGA need to reload its config each time it's powered. It can download >> it's config from a little flash on the board (so that the board is >> autonomous) and this PROM is on the JTAG chain too, but you can't >> program it with this application yet. >> >> >> Personnaly, I'm now doing all my Xilinx work under Linux. >> >> I use wine for the WebPack. That's sometimes a little slow when >> "compiling" but that's OK. And this prog to program the bitstream. >> The only thing I can't do is program the PROM. >> > > In due course I'll be working on programming the PROM. At the moment I'm > struggling to find a datasheet on the XCF02S PROM that gives the > programming algorithm. Even without the datasheet I will not give up. > > Can anyone tell me where I can find the programming algorithm for the > XCF02S PROM? > > Thanks > Andrew > http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-18786&iLanguageID=1 One would think that the "Complete data sheet for Platform Flash In-System Programmable Configuration PROMs" would have details on the "In-System Programmable" features. I think the marketing department has been at work here! It does give: Instruction register length. IDCODE. Instruction capture values. JTAG signals timing. It does not tell me about "In-System Programmable"! "Complete" ? Regards Andrew -- Spartan3 configuration download tool for GNU/Linux available from http://www.rogerstech.co.ukArticle: 72333
byseid@yahoo.com writes: > I am not new for logic design but I need help for designing a > sequential Logic circuit analysis and design. > I want to design a traffic light controller for crossroad(of four > direction) the controller at each direction say A,B,C,D detects the > number of cars on each then the line having more cars will get the > priority... for more details please mail me <byseid@yahoo.com>. If I do your homework for you, will you please have your school award the degree in my name?Article: 72334
I have added a section about the LEGO motor driver on the website (http://www.jopdesign.com/lego/index.jsp). You can find mesurements of the PWM output from the original LEGO RCX, a simple schemantic with an L283D driver and sigma-delta ADCs for back-EMF measurements. Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 72335
This is a multi-part message in MIME format. --------------080302030505090600010304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Alistair, alastair wrote: > It's been a while since I did any development with XPS (that's my > excuse) and after checking the memory map for the BRAM controllers I > get past the error I saw. Now I get another one when generating the > bitstream: > > ERROR:Ncd:528 - Could not find the the corresponding NC_COMP for the > BlockRAM > instancename:<bram_lmb_2/bram_block_0_i/ramb16_s9_s9_0>.Cannot > continue with > BlockRAM updates. > ERROR:Bitgen:194 - Unable to update BRAM initialization data for > design > system.ncd. > make: *** [implementation/system.bit] Error 1 > Done. Looks like the data2bram utility that stuffs bram contents onto the bitstream, is having trouble distinguishing the various BRAMs. Did you do a "make clean" after you fixed the initial error, and build it all from scratch? > John - if you have time to dig out your project with dual processors > I'd appreciate being able to have a look at the setup. I'm not sure > what the error means and can't seem to find any information on the > error from a quick search on Google and the Xilinx website - any ideas The MHS file is attached. This harwdare will build under 6.2, but I don't think it will actually work. Note it's an SMP system, two microblazes on the same bus which is not what you wanted. As such there are other issues such as cache coherency (lack thereof), and no interrupt sharing etc, but it's a starting point. Cheers, John --------------080302030505090600010304 Content-Type: text/plain; name="system.mhs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="system.mhs" # Parameters PARAMETER VERSION = 2.1.0 # Global Ports PORT ext_clk = ext_clk, DIR = IN PORT ddr_clk_fb = ddr_clk_fb, DIR = IN PORT sys_rstn = sys_rstn, DIR = IN PORT console_uart_rx = console_uart_rx, DIR = IN PORT console_uart_tx = console_uart_tx, DIR = OUT PORT debug_uart_rx = debug_uart_rx, DIR = IN PORT debug_uart_tx = debug_uart_tx, DIR = OUT PORT sram_cen = sram_cen, DIR = OUT, VEC = [0:1] PORT sram_addr = sram_addr, DIR = OUT, VEC = [0:31] PORT sram_ben = sram_ben, DIR = OUT, VEC = [0:3] PORT sram_data = sram_data, DIR = INOUT, VEC = [0:31] PORT sram_oen = sram_oen, DIR = OUT PORT sram_wen = sram_wen, DIR = OUT PORT sram_rst = sram_rst, DIR = OUT PORT gpio = gpio, DIR = INOUT, VEC = [0:23] PORT ddr_clk = ddr_clk, DIR = OUT PORT ddr_clkn = ddr_clkn, DIR = OUT PORT ddr_clke = ddr_clke, DIR = OUT PORT ddr_csn = ddr_csn, DIR = OUT PORT ddr_rasn = ddr_rasn, DIR = OUT PORT ddr_casn = ddr_casn, DIR = OUT PORT ddr_wen = ddr_wen, DIR = OUT PORT ddr_dqm = ddr_dqm, DIR = OUT, VEC = [0:1] PORT ddr_bankaddr = ddr_bankaddr, DIR = OUT, VEC = [0:1] PORT ddr_addr = ddr_addr, DIR = OUT, VEC = [0:12] PORT ddr_dq = ddr_dq, DIR = INOUT, VEC = [0:15] PORT ddr_dqs = ddr_dqs, DIR = INOUT, VEC = [0:1] PORT ETH_COL = ETH_COL, DIR = IN PORT ETH_CRS = ETH_CRS, DIR = IN PORT ETH_MDC = ETH_MDC, DIR = INOUT PORT ETH_MDIO = ETH_MDIO, DIR = INOUT PORT ETH_RXC = ETH_RXC, DIR = IN PORT ETH_RXD = ETH_RXD, DIR = IN, VEC = [3:0] PORT ETH_RXDV = ETH_RXDV, DIR = IN PORT ETH_RXER = ETH_RXER, DIR = IN PORT ETH_TXC = ETH_TXC, DIR = IN PORT ETH_TXD = ETH_TXD, DIR = OUT, VEC = [3:0] PORT ETH_TXEN = ETH_TXEN, DIR = OUT PORT ETH_TXER = ETH_TXER, DIR = OUT PORT PHY_RESETn = PHY_RESETn, DIR = OUT # Sub Components BEGIN microblaze PARAMETER INSTANCE = microblaze_0 PARAMETER HW_VER = 2.00.a PARAMETER C_USE_DIV = 0 PARAMETER C_USE_BARREL = 0 PARAMETER C_DEBUG_ENABLED = 0 PARAMETER C_USE_ICACHE = 1 PARAMETER C_ICACHE_BASEADDR = 0x80000000 PARAMETER C_ICACHE_HIGHADDR = 0x81FFFFFF PARAMETER C_CACHE_BYTE_SIZE = 8192 PARAMETER C_ADDR_TAG_BITS = 11 BUS_INTERFACE DLMB = d_lmb_v10 BUS_INTERFACE ILMB = i_lmb_v10 BUS_INTERFACE DOPB = d_opb_v20 BUS_INTERFACE IOPB = d_opb_v20 PORT CLK = sys_clk PORT INTERRUPT = interrupt END BEGIN microblaze PARAMETER INSTANCE = microblaze_2 PARAMETER HW_VER = 2.00.a PARAMETER C_USE_DIV = 0 PARAMETER C_USE_BARREL = 0 PARAMETER C_DEBUG_ENABLED = 0 PARAMETER C_USE_ICACHE = 1 PARAMETER C_ICACHE_BASEADDR = 0x80000000 PARAMETER C_ICACHE_HIGHADDR = 0x81FFFFFF PARAMETER C_CACHE_BYTE_SIZE = 8192 PARAMETER C_ADDR_TAG_BITS = 11 BUS_INTERFACE DLMB = d2_lmb_v10 BUS_INTERFACE ILMB = i2_lmb_v10 BUS_INTERFACE DOPB = d_opb_v20 BUS_INTERFACE IOPB = d_opb_v20 PORT CLK = sys_clk #PORT INTERRUPT = interrupt END # inverter to convert active low sys_rstn to active high sys_rst BEGIN my_inverter PARAMETER INSTANCE = rst_inverter PORT I = sys_rstn PORT O = sys_rst END BEGIN ddr_clk_gen PARAMETER INSTANCE = my_ddr_clk_gen PARAMETER HW_VER = 1.00.a # 66mhz internal clock PARAMETER C_CLKIN_PERIOD_NS = 15.0 # 66mhz external clock PORT CLK_IN = clk66mhz # tie DCM reset to system reset (active low) PORT CLK_RST = sys_rst # feedback from outside PORT DDR_CLK_FB = ddr_clk_fb # drive system clock with this one PORT CLK0 = sys_clk # 90 deg phase shifted system clock PORT CLK90 = sys_clk_90 # external feedback 90 deg phase shift PORT DDR_CLK_90 = ddr_clk_90 END # PORT CORE_DCM_LOCKED = core_dcm_locked # PORT DDR_DCM_LOCKED = ddr_dcm_locked BEGIN opb_ddr PARAMETER INSTANCE = ddr_controller PARAMETER HW_VER = 1.00.b # 100mhz clock PARAMETER C_OPB_CLK_PERIOD_PS = 15000 PARAMETER C_INCLUDE_BURST_SUPPORT = 0 PARAMETER C_DQS_PULLUPS = 1 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_TREFC = 70000000 PARAMETER C_DDR_TREFI = 7800000 PARAMETER C_DDR_TRP = 20000 PARAMETER C_DDR_CAS_LAT = 2 PARAMETER C_DDR_DWIDTH = 16 PARAMETER C_DDR_AWIDTH = 13 PARAMETER C_DDR_COL_AWIDTH = 9 PARAMETER C_DDR_BANK_AWIDTH = 2 PARAMETER C_BASEADDR = 0x80000000 PARAMETER C_HIGHADDR = 0x81FFFFFF BUS_INTERFACE SOPB = d_opb_v20 # system clock PORT OPB_Clk = sys_clk # phase shifted sys_clk PORT Clk90_in = sys_clk_90 # phase shifted feedback clk PORT DDR_Clk90_in = ddr_clk_90 # output clocks PORT DDR_Clk = ddr_clk # inverted clock PORT DDR_Clkn = ddr_clkn PORT DDR_CKE = ddr_clke PORT DDR_CSn = ddr_csn PORT DDR_RASn = ddr_rasn PORT DDR_CASn = ddr_casn PORT DDR_WEn = ddr_wen PORT DDR_DM = ddr_dqm PORT DDR_BankAddr = ddr_bankaddr PORT DDR_Addr = ddr_addr PORT DDR_DQ = ddr_dq PORT DDR_DQS = ddr_dqs END BEGIN opb_memcon PARAMETER INSTANCE = system_memcon PARAMETER HW_VER = 1.00.a PARAMETER C_OPB_CLOCK_PERIOD_PS = 15000 PARAMETER C_NUM_BANKS_MEM = 2 PARAMETER C_BASEADDR = 0xffff0000 PARAMETER C_HIGHADDR = 0xffff00ff PARAMETER C_MEM0_BASEADDR = 0xffe00000 PARAMETER C_MEM0_HIGHADDR = 0xffefffff PARAMETER C_MEM1_BASEADDR = 0xff000000 PARAMETER C_MEM1_HIGHADDR = 0xff7fffff BUS_INTERFACE SOPB = d_opb_v20 PORT Mem_CEN = sram_cen PORT Mem_A = sram_addr PORT Mem_BEN = sram_ben PORT Mem_DQ = sram_data PORT Mem_OEN = sram_oen PORT Mem_WEN = sram_wen PORT OPB_Clk = sys_clk PORT Mem_RPN = sram_rst END BEGIN opb_uartlite PARAMETER INSTANCE = console_uart PARAMETER HW_VER = 1.00.b PARAMETER C_BAUDRATE = 57600 PARAMETER C_DATA_BITS = 8 PARAMETER C_USE_PARITY = 0 PARAMETER C_ODD_PARITY = 0 PARAMETER C_CLK_FREQ = 66_666_667 PARAMETER C_BASEADDR = 0xFFFF2000 PARAMETER C_HIGHADDR = 0xFFFF20FF BUS_INTERFACE SOPB = d_opb_v20 PORT Interrupt = console_uart_interrupt PORT OPB_Clk = sys_clk PORT RX = console_uart_rx PORT TX = console_uart_tx END BEGIN opb_uartlite PARAMETER INSTANCE = debug_uart PARAMETER HW_VER = 1.00.b PARAMETER C_DATA_BITS = 8 PARAMETER C_CLK_FREQ = 66_666_667 PARAMETER C_BAUDRATE = 115200 PARAMETER C_USE_PARITY = 0 PARAMETER C_ODD_PARITY = 0 PARAMETER C_BASEADDR = 0xFFFF4000 PARAMETER C_HIGHADDR = 0xFFFF40FF BUS_INTERFACE SOPB = d_opb_v20 PORT Interrupt = debug_uart_interrupt PORT OPB_Clk = sys_clk PORT RX = debug_uart_rx PORT TX = debug_uart_tx END BEGIN opb_intc PARAMETER INSTANCE = system_intc PARAMETER HW_VER = 1.00.c PARAMETER C_BASEADDR = 0xffff3000 PARAMETER C_HIGHADDR = 0xffff30ff BUS_INTERFACE SOPB = d_opb_v20 PORT Irq = interrupt PORT OPB_Clk = sys_clk PORT Intr = ethernet_interrupt & debug_uart_interrupt & console_uart_interrupt & timer_interrupt END BEGIN opb_timer PARAMETER INSTANCE = system_timer PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0xffff1000 PARAMETER C_HIGHADDR = 0xffff10ff BUS_INTERFACE SOPB = d_opb_v20 PORT OPB_Clk = sys_clk PORT Interrupt = timer_interrupt END BEGIN opb_gpio PARAMETER INSTANCE = system_gpio PARAMETER HW_VER = 1.00.a PARAMETER C_BASEADDR = 0xffff5000 PARAMETER C_HIGHADDR = 0xffff50ff PARAMETER C_GPIO_WIDTH = 24 BUS_INTERFACE SOPB = d_opb_v20 PORT GPIO_IO = gpio PORT OPB_Clk = sys_clk END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = d_lmb_bram_if_cntlr PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001FFF BUS_INTERFACE SLMB = d_lmb_v10 BUS_INTERFACE BRAM_PORT = conn_0 PORT LMB_Clk = sys_clk END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = i_lmb_bram_if_cntlr PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001FFF BUS_INTERFACE SLMB = i_lmb_v10 BUS_INTERFACE BRAM_PORT = conn_1 PORT LMB_Clk = sys_clk END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = d_lmb_bram_if_cntlr2 PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001FFF BUS_INTERFACE SLMB = d2_lmb_v10 BUS_INTERFACE BRAM_PORT = conn_3 PORT LMB_Clk = sys_clk END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = i_lmb_bram_if_cntlr2 PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00001FFF BUS_INTERFACE SLMB = i2_lmb_v10 BUS_INTERFACE BRAM_PORT = conn_4 PORT LMB_Clk = sys_clk END BEGIN bram_block PARAMETER INSTANCE = bram PARAMETER HW_VER = 1.00.a PARAMETER C_MEMSIZE = 8192 BUS_INTERFACE PORTA = conn_0 BUS_INTERFACE PORTB = conn_1 END BEGIN bram_block PARAMETER INSTANCE = bram2 PARAMETER HW_VER = 1.00.a PARAMETER C_MEMSIZE = 8192 BUS_INTERFACE PORTA = conn_3 BUS_INTERFACE PORTB = conn_4 END BEGIN opb_v20 PARAMETER INSTANCE = d_opb_v20 PARAMETER HW_VER = 1.10.b PORT OPB_Clk = sys_clk PORT SYS_Rst = sys_rst END BEGIN lmb_v10 PARAMETER INSTANCE = i_lmb_v10 PARAMETER HW_VER = 1.00.a PORT LMB_Clk = sys_clk PORT SYS_Rst = sys_rst END BEGIN lmb_v10 PARAMETER INSTANCE = d_lmb_v10 PARAMETER HW_VER = 1.00.a PORT LMB_Clk = sys_clk PORT SYS_Rst = sys_rst END BEGIN lmb_v10 PARAMETER INSTANCE = i2_lmb_v10 PARAMETER HW_VER = 1.00.a PORT LMB_Clk = sys_clk PORT SYS_Rst = sys_rst END BEGIN lmb_v10 PARAMETER INSTANCE = d2_lmb_v10 PARAMETER HW_VER = 1.00.a PORT LMB_Clk = sys_clk PORT SYS_Rst = sys_rst END BEGIN my_dcm PARAMETER INSTANCE = system_dcm PARAMETER HW_VER = 1.00.a PARAMETER C_CLKIN_PERIOD_NS = 10.0 PARAMETER C_DIVISOR = 3 PARAMETER C_INBUFFER = TRUE PARAMETER C_MULTIPLIER = 2 PARAMETER C_OUTBUFFER = TRUE # external clock input pin PORT CLK_IN = ext_clk PORT CLK_RST = net_gnd PORT CLK_0 = clk_fb_o PORT CLK_FB = clk_fb_i # input to ddr_clk_gen module PORT CLK_FX = clk66mhz END BEGIN my_bufg PARAMETER INSTANCE = dcm_feedback_bufg PORT I = clk_fb_o PORT O = clk_fb_i END BEGIN opb_ethernet PARAMETER INSTANCE = ether PARAMETER HW_VER = 1.00.m PARAMETER C_DMA_PRESENT = 1 PARAMETER C_DMA_INTR_COALESCE = 1 PARAMETER C_OPB_CLK_PERIOD_PS = 15000 PARAMETER C_BASEADDR = 0xC0000000 PARAMETER C_HIGHADDR = 0xC0003FFF BUS_INTERFACE MSOPB = d_opb_v20 PORT OPB_Clk = sys_clk PORT OPB_Rst = sys_rst PORT PHY_col = ETH_COL PORT PHY_crs = ETH_CRS PORT PHY_Mii_clk = ETH_MDC PORT PHY_Mii_data = ETH_MDIO PORT PHY_rx_clk = ETH_RXC PORT PHY_rx_data = ETH_RXD PORT PHY_dv = ETH_RXDV PORT PHY_rx_er = ETH_RXER PORT PHY_tx_clk = ETH_TXC PORT PHY_tx_data = ETH_TXD PORT PHY_tx_en = ETH_TXEN PORT PHY_tx_er = ETH_TXER PORT PHY_rst_n = PHY_RESETn PORT Freeze = net_gnd PORT IP2INTC_Irpt = ethernet_interrupt END --------------080302030505090600010304--Article: 72336
On 15 Aug 2004 12:08:02 -0700, Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: >byseid@yahoo.com writes: >> I am not new for logic design but I need help for designing a >> sequential Logic circuit analysis and design. >> I want to design a traffic light controller for crossroad(of four >> direction) the controller at each direction say A,B,C,D detects the >> number of cars on each then the line having more cars will get the >> priority... for more details please mail me <byseid@yahoo.com>. > >If I do your homework for you, will you please have your school award >the degree in my name? A still quite funny post from Bob Perlman on this subject from the archive: http://www.fpga-faq.com/archives/52250.html#52254 philipArticle: 72337
"Andrew Rogers" <andrew@_NO_SPAM_rogerstech.co.uk> wrote in message news:411f6623_1@127.0.0.1... > Sylvain Munaut wrote: > In due course I'll be working on programming the PROM. At the moment I'm > struggling to find a datasheet on the XCF02S PROM that gives the > programming algorithm. Even without the datasheet I will not give up. > > Can anyone tell me where I can find the programming algorithm for the > XCF02S PROM? I think its not published! but that doesnt mean it cant be programmed. just generated SVF and look what is done there :) Antti http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=3833881729Article: 72338
hi everybody. i was just wondering if it is possible for any combinational vhdl code to utilize the same amount of logic cells while optimizing area and speed both?also with the same max. propagation delay in both cases? the code i tried to run on xilinx ISE webpack 6.2i is: library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; use ieee.std_logic_arith.all; entity testarith is port ( Asigned : in signed ( 15 downto 0 ); Bsigned : in signed ( 15 downto 0 ); Cstd : in std_logic_vector ( 15 downto 0 ); Dstd : in std_logic_vector ( 15 downto 0 ); Qab : out signed ( 15 downto 0 ); Mab : out signed ( 31 downto 0 ); Qcd : out std_logic_vector ( 15 downto 0 ); Mcd : out std_logic_vector ( 31 downto 0 )); end testarith; architecture behv of testarith is begin Qab <= Asigned + Bsigned; Mab <= Asigned * Bsigned; Qcd <= Cstd - Dstd; Mcd <= Cstd * Dstd; end behv; i got the same results for speed optimization as well as area optimization? waiting anxiously for the reply. Thank You ShahabuddinArticle: 72339
On 13 Aug 2004 06:09:36 -0700, brucewillis@freenet.de (Bruce) wrote: [snip] >Or is there any example >implementation for the whole CRC calculation inside the FPGA fabric >available? I wonder how one could ever reach the typical 2.5 Gbit/s >Infiniband transmission rate when almost all functions must be handled >inside the FPGA fabric? Hmmm. I worked on designs last century that performed CRCs on 10Gbit/s data streams. FPGAs have improved since then, perhaps doubling in speed. 2.5Gbit/s sounds rather easy, assuming you know the tricks. I tried to summarise the high speed CRC tricks in this post: http://groups.google.com/groups?threadm=u4ll7v0d9naejd0clk064e6u5baud8sdo4%404ax.com Regards, Allan.Article: 72340
"Andrew Rogers" <andrew@_NO_SPAM_rogerstech.co.uk> wrote in message news:411fb0f8$1_1@127.0.0.1... [snip] > > > > In due course I'll be working on programming the PROM. At the moment I'm > > struggling to find a datasheet on the XCF02S PROM that gives the > > programming algorithm. Even without the datasheet I will not give up. > > > > Can anyone tell me where I can find the programming algorithm for the > > XCF02S PROM? > > > > Thanks > > Andrew > > [snip] I'm not sure if the links contain the information that you're after, but it may be a start. The 18V00 family is not the same as Platform Flash, but the general approach is similar. Answer Record #10423 18V00 PROM's - Is the programming algorithm available? http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=10423 XAPP058: Xilinx In-System Programming Using an Embedded Microcontroller http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 72341
Hi Nigel, Thanks for the quick answer. I have a webcase opened to try to get the latest vhdl design out of Coregen and if I can get them no need for me to fix this old design. So far with Coregen I could only generate and test the code for single lane design. In the meantime I thought I should fix the old 4 lane design to prove the 4-lanes solution. So far it works with almost random data and I guess this patch is all I'm missing. I don't want to waste your time doing the conversion. A verilog patch will be fine. If it is an easy fix I'll convert it to the vhdl if not I'll wait for the webcase to help me to get the latest design. If you have the file I'll be glad if you can forward it to me. I'll send you an e-mail so that you get my address. Thanks and Best Regards, Jeremie. "Nigel Gulstone" <nigel.gulstone@xilinx.com> wrote in message news:411CF536.DD67C00D@xilinx.com... > Hi Jeremie, > > I'm sorry to say that the zip file you are looking for only contains a > Verilog version of the patch. It was originally produced by special request > for a customer who could not upgrade to one of our newer designs: they had > made custom changes to the old module. > > In general we recommend an upgrade to one of the modules from the > Xilinx Core Generator tool - these are the smallest Aurora designs we offer, > and have the same interface as the old designs. I would be happy to create a > VHDL version of the patch for you. If you contact me directly or pass the > message along via your FAE or hotline, I'll do my best to help you out. > > In hindsight, we should have provided both languages in the zip file. > We're working to fix the broken link on the server - when its up and running > again, we'll add the VHDL version of the patch to the zip file. > > Cheers, > Nigel > > > Jeremie Veyret wrote: > > > Hi, > > > > I'm using Xilinx 804 aurora vhdl design and I saw that on their web-site > > that there was a patch for it (Record Number: 18554) but the file is not > > available on their server anymore. > > I asked them and they seem to have problem finding it back. > > If any of you sees what I mean and has downloaded the patch called > > aurora_804_sp_patch.zip > > Could you let me know and I'll contact you directly (I'm not too fond of > > spam). > > > > Best regards, > > > > Jeremie. >Article: 72342
Ken McElvain <ken@synplicity.com> wrote in message news:<411C3EF1.7060005@synplicity.com>... > Identify will display enum types directly. Everything > is done in terms of the RTL source. No guessing. It's just a tad more expensive though, eh? Cheers, JonBArticle: 72343
I'm working with a NIOS II cpu on an Altera Stratix chip. I'm finding it easy enough to make simple Avalon slave devices, using the "interface to user logic" wizard to connect my components to the bus. But I can't find any way to deal with memory devices that would logically connect to tristate buses. I have a couple of synchronous ram devices which should be simple enough to use (I can access them using a test module I made outside the NIOS). Is there any simple way of connecting new devices to a tristate bus, or any application notes that show how? Thanks, -- David "I love deadlines. I love the whooshing noise they make as they go past." Douglas AdamsArticle: 72344
>> Does anyone know if there exists an FPGA development board that has >> a PCI express interface? I would also be nice if it had video i/o on >> board I need to do real time quick image processing, and eventually >> face detection algorithms... > > I haven't used either of these but they're the only ones I've come > across so far: > > http://www.nallatech.com/solutions/products/kits/pci-express_design/ > http://www.nital.com/corporate/pciexbuilder-e254.html PLDA makes a PCI express board that also has a PCI/PCI-X interface: http://www.plda.com/pdt_boards_pciexp.htmArticle: 72345
The following is the snippet of C code to test SDRAM connected to OPB
from MEMEC design resources.
// Type casting
unsigned int* sdram_location = (unsigned int *) XPAR_SDRAM1_BASEADDR;
int sdram_data_read, sdram_data_read_error;
unsigned int* temp;
//Store values
temp = sdram_location;
for (loop_count = 0; loop_count < 4194304; loop_count++) {
*sdram_location = loop_count;
sdram_location++;
}
//Retrieve values
sdram_location = temp;
for (loop_count = 0; loop_count < 4194304; loop_count++) {
sdram_data_read = *sdram_location;
if (sdram_data_read != loop_count) {
printf_uart(" SDRAM Test Failed\n\r");
loop_count = 4194305;
}
else {
sdram_location++;
}
}
hope this helps
Ram
Michael Dales <mwd24@thompson.cl.cam.ac.uk> wrote in message news:<yqmwu03xobn.fsf@thompson.cl.cam.ac.uk>...
> Hi there,
>
> We have a Xilinx AFX FF1152 Virtex-II Pro board with a xc2vp20 on
> it. I have tried to get a simple design up usign the SDRAM, but the
> memory check code inserted by EDK fails (the code lives in the PLB
> BRAM, and EDK kindly included a memory checker for the SDRAM).
>
> On the FPGA I'm using one of the PPC cores, which is connected to
> some BRAM over the PLB, and to an SDRAM interface on the PLB
> (basically this is what the system builder wizard creates for
> you). EDK doesn't support out specific AFX board, so I've manually
> updated the pin assignment information in the UCF file to match that
> in the documentation.
>
> For clocking, I'm using a 100 MHz oscillator in the socket marked
> RAM/FPGA, which as I understand it will clock the SDRAM and provide me
> a clock on pin D18. This clock is then fed through a DCM and the
> output of CLK0 is used as the OPB bus clock and fed into the OPB-SDRAM
> interface core.
>
> The RAM enable jumper is set to on.
>
> When I try to test the memory it fails. If I write a bunch of data to
> the SDRAM and read it back I just get the last value I wrote.
>
> Any suggestions as to what I might have missed?
Article: 72346Gerd wrote: > Uh? > It's not _that_ bad, isn't it? Yes, it is. :) > As for the tools being buggy, if your talking about modular design flow, > then probably everybody agrees, but otherwise you shuold be fine. At least > the ICAP is easier to handle than the SelectMAP (see my other post :( ). The modular design flow isn't the only problem. If you have a dozen or so signals crossing a reconfigurable module and have to start using bus macros (and not just one or two), you get a different "FATAL_ERROR" every day... > Regarding the placement of the MicroBlaze, it really takes up so much area > that I wouldn't consider it _better_ than the PPC. In fact with the PPC, > you only loose the couple columns associated with that PPC (and you can > area-constrain the ppc-icap-interface to those same columns), which should > be less than the number of columns required for a Microblaze in the smaller > devices (up to 2vp20 I would guess). <rantmode> The problem is that when you use the PPC, you're pretty much fixed in where you can put what module. Plus there's the problem of board layout... in my case, I used the Virtex II-Pro Development Board from Memec, which has the SDRAM connected to the pins on "the left side" (if you look at the FPGA like Floorplanner and FPGA Editor do), whereas the PPC sits on the "right side". Now if you need to load a partial bitstream from SDRAM, you need to hook up the SDRAM on the left side to the PowerPC on the right side, so where do you put the reconfigurable module? Right, in between... which gives you the problem of crossing the reconfigurable module with 32 SDRAM data-signals, times 2 because it's bi-directional and the bus macros don't support bi-directional signals, plus the signals for the address bus, plus the byte-enables, and so on. In the end you have to cross the reconfigurable module with 80 or 90 signals, most of which are time-critical, using bus macros... and you can't use the ones from xapp290, since you want to *CROSS* a module, not connect two adjacent ones... which means you have to draw the macros yourself with FPGA Editor... which means you're going to lose what little hair you have left on your head because the damn thing keeps crashing every 5 minutes... And if you hit the "save" button once too often, it leaves you with an nmc-file you can't read, because FPGA Editor will serve you another "FATAL_ERROR"... But FPGA Editor forgets some important attributes when saving bus macros, so now you have to use XDL to convert the macro to XDL, add the attribute and convert it back to NMC... but then you can't open the macro in FPGA Editor anymore, because it will remove the attribute, even if you don't hit the "save"-button... But after you finally have managed to get bus macros that support what you want to do with them, the *REAL* fun begins... Now you get more "FATAL_ERRORS", because the tools can't place the macros the way you want them to... and if they finally do, they start routing nets into the reconfigurable module area, ignoring the constraints you set.. and after a while you find out that the only way to get that work is to not let the macros end at the module border, but instead move a few slices into the module. So now you have to fire up FPGA Editor again to draw new bus macros, this time a little wider, and the fun begins again... The easiest solution in my case was to just forget about the PPC and use the MicroBlaze instead, and put it right next to the SDRAM => no more module crossing, problem solved... If you don't have any or very little inter-module communication, there shouldn't be any problems, but you can hardly avoid that unless you design your board to suit this kind of application in the first place. </rantmode> Phew, that felt good... :) > Anyway, if you have any specific problems with the ICAP, please ask :) No, ICAP is not the problem... except for the fact that still noone can tell me why you can't clock it with the same frequency as SelectMAP, even though it's supposed to be nothing other than an internal connection to the same SelectMAP-interface... But the *REAL* problem with all of this is that you can't do the *REALLY* fun stuff anyway, since a) all you can reconfigure are complete frames from top to bottom of the device and b) the architecture of the Virtex II-Pro bitstream has not been disclosed, so you don't know which bits to change to e.g. change filter coefficients or something like that... So what can you really do with it? Change RocketIO-parameters (but only because Xilinx has disclosed the necessary info for this one particular case) and reconfigure entire modules, but that's only fun if you don't have any communication between modules. So what's left? Sure, you could spent a few weeks or months revers engineering the bitstream format, and *THEN* it could be fun... But I'd be interested to know what you guys (or anyone else) use partial reconfiguration for? From my point of view, it's a nice "gimmick", an interesting research subject, but there's no "real-life application" that justifies the extra effort... cu, SeanArticle: 72347
Hi John, Thanks for posting the system - a combination of this and going through my system with a careful eye got things working in the end :) The final stumbling block was to make sure the reset signals for the local memory buses were of the correct polarity. Thanks again, Alastair.Article: 72348
ramntn@yahoo.com (ram) writes:
> The following is the snippet of C code to test SDRAM connected to OPB
> from MEMEC design resources.
Thanks for the reply, but what I was really after was advice relating
to the design I've implemented. I'd already implemented my own code to
verify that either the SDRAM was failing or my design wasn't using the
SDRAM connectly. What I'm trying to understand if *why* the SDRAM
isn't working, despite having done everything the documentation
suggests (to the best of my knowledge).
The design practically left everything up to the base system builder,
and the only thing I did was correct the pin definitions in the UCF
board, and ensure that I was using the correct oscillator socket, and
that the DRAM enable pin was set corrently.
I'm told that SDRAM chips are very sensitive to the clock they're
given, and that if it says it is to be clocked at a specific frequency
it really means that. I failed to find appropriate documentation for
the SDRAM chip on the AFX board we have - the URL in the board
documentation is no longer valid, and searching the web site the for
the makings on the chip (1QE42 ZVCGC) didn't turn up anything either.
>
> // Type casting
> unsigned int* sdram_location = (unsigned int *) XPAR_SDRAM1_BASEADDR;
> int sdram_data_read, sdram_data_read_error;
> unsigned int* temp;
>
> //Store values
> temp = sdram_location;
> for (loop_count = 0; loop_count < 4194304; loop_count++) {
> *sdram_location = loop_count;
> sdram_location++;
> }
>
> //Retrieve values
> sdram_location = temp;
> for (loop_count = 0; loop_count < 4194304; loop_count++) {
> sdram_data_read = *sdram_location;
>
> if (sdram_data_read != loop_count) {
> printf_uart(" SDRAM Test Failed\n\r");
> loop_count = 4194305;
Whoever wrote this code needs to be introduced to the C keyword
"break" :)
> }
> else {
> sdram_location++;
> }
> }
>
> hope this helps
> Ram
Cheers,
--
Michael Dales
University of Cambridge Computer Laboratory
http://www.cl.cam.ac.uk/~mwd24/
Article: 72349Hi Sean, Sean Durkin <smd@despammed.com> wrote: > > It's not _that_ bad, isn't it? > Yes, it is. :) Naa ;-) > The modular design flow isn't the only problem. If you have a dozen or > so signals crossing a reconfigurable module and have to start using bus > macros (and not just one or two), you get a different "FATAL_ERROR" > every day... Now I know where your problem lies.. however, that problem has been solved :) First, don't use bus macros unless really necessary. For what you describe here, directed routing combined with a few placement constraints is probably an easier and more reliable solution than bus macros. And I bet in many cases you don't even have to bother with directed routing. > <rantmode> [...] > layout... in my case, I used the Virtex II-Pro Development Board from > Memec, which has the SDRAM connected to the pins on "the left side" (if It's the same for the ML300 and most other V2Pro boards I have seen, unfortunately. > the PowerPC on the right side, so where do you put the reconfigurable > module? Right, in between... which gives you the problem of crossing the Depends on the size of your module. You could put it on the right hand side of the PPC - on a 2vp7, you can get about 1000..1200 slices there (with space left for cross-routing - read on). If you put it in the middle, you obviously have pretty much as many slices as you want, within the limits of the chosen device of cause. Now, there is a very simple trick to getting around of having to build all those bus macros: divide the reconfigurable frames into parts for your module, and parts reserved for cross-routing. Now area-constrain the logic which requires cross-routing in such a way that the routes only go through the designated area (unfortunately you can't area-constrain the routing.. the whole constraints business has lot's of room for improvement). So to stick to your example with the SDRAMs and assuming you are using an plb-sdram-controller, constrain the sdram-controller to the left, the plb-part of the controller to the lower left, the plb bus core to the lower right, and your cross-routing will go only through the lower part of your device. Your module obviously goes to the upper middle section. Continue along this line of thought for a bit and you should come to a feasible solution for modules, including cross-routing (actually, from this point on there are at least two possible paths, one with static bitfiles and one with a more dynamic approach to reconfiguration; both have been implemented successfully). > The easiest solution in my case was to just forget about the PPC and use > the MicroBlaze instead, and put it right next to the SDRAM => no more > module crossing, problem solved... Fair enough. But unless you specially design a board for reconfigurable applications, you'll most likely always end up having cross-routing in one way or another. > > Anyway, if you have any specific problems with the ICAP, please ask :) > No, ICAP is not the problem... except for the fact that still noone can > tell me why you can't clock it with the same frequency as SelectMAP, > even though it's supposed to be nothing other than an internal > connection to the same SelectMAP-interface... Well, who says you can't? Just watch the BUSY signal. > But the *REAL* problem with all of this is that you can't do the > *REALLY* fun stuff anyway, since a) all you can reconfigure are complete > frames from top to bottom of the device and b) the architecture of the Well, yes and no. I have multiple modules on top of each other working, 'on top' like SLICE_XiY8:SLICE_XjY31 and SLICE_XiY40:SLICE_XjY71 for example. They can be reconfigured without interference - as long as you don't have SRL16s and LUT-RAMs in the columns, of cause. > Virtex II-Pro bitstream has not been disclosed, so you don't know which > bits to change to e.g. change filter coefficients or something like > that... So what can you really do with it? Change RocketIO-parameters That's not exactly true, either. Of cause one has to look a bit harder for this information, but it is actually contained to some degree in the EDK6.2 icap drivers, and there is quite some information strewn across various appnotes and answer records as well. No single source covers it all, though - agreed. > (but only because Xilinx has disclosed the necessary info for this one > particular case) and reconfigure entire modules, but that's only fun if > you don't have any communication between modules. So what's left? Sure, > you could spent a few weeks or months revers engineering the bitstream > format, and *THEN* it could be fun... It should be faster than that, with a bit of XDL hacking :) > But I'd be interested to know what you guys (or anyone else) use partial > reconfiguration for? From my point of view, it's a nice "gimmick", an > interesting research subject, but there's no "real-life application" > that justifies the extra effort... Real life as in space applications - check out Carl Carmichaels papers about irradiation testing, there is a note about in-situ repair using partial reconfiguration (although to be really useful here requires a bit harsher environments than simple space). Reconfigurable modules are a practical application - the hardest part IMHO is the communcation between the reconfigurable module and the rest of the logic (say, the PPC), because that actually _does_ require bus macros. Some people supposedly use genetic algorithms to program FPGAs and using partial reconfiguration can signifcantly speed up this process (and the evaluation of the results). There are also several useful applications which 'only' require the reconfiguration of routing, though I guess I shouldn't go into any details about these. regards, Gerd Credit where credit is due: the genetic thing is from a chat I had on FPGA conference this year, although I don't remember the name of the person whom I talked with; also to Tobias Becker who proved the 'static approach' mentioned above by just doing it :). Oh and if you happen to be on FPL in two weeks, maybe there will be a presentation of a simple case of the 'on top' modules. It could be arranged, anyway.
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