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 Chris, > Does anybody know of a good, --small--, development board with an > ethernet port? What I'm really looking for is essentially a FPGA, on > a very small PCB, with an ethernet port and power port/headers. Some > extra pins brought out to headers would be handy, but are not > essential. While I'm dreaming, it needs to be something I could > communicate to from linux, so proprietary / windows-only ethernet > drivers won't cut it. Take a look here. Boards are preconfigured with uCLinux, and have standard 2.54mm headers. http://shop.trenz-electronic.de/catalog/default.php?cPath=1_51 best regards Thorsten TrenzArticle: 115901
Hello there, I have a query for the more knowledgeable than me.. We've been playing quite successfully with 1 gig Ethernet in our labs that we're getting bold and want to move to 10Gig. I was wondering if anyone else had experience of the various phy layer transceivers that are available. We're about to sign the NDA's for Marvell, Vitesse and Broadcom (if they ever get back to me....) so we can get details on the various chips. But helpful hints from anyone here would be nice.. The 10gig side will probably be an XFP interface cage, as we have a couple of 10gig PCIexpress NICs that use those. Stealing an XPF fibre module from that side of the lab is the easy part *wink* I saw a powerpoint with info on the Xilinx RocketPHY chip, does that still exist?? The links I tried all refused to work.. Our current board (Virtex4FX60 based, it has PCIexpress connector for going into an 8lane socket, and also has a 4lane socket on it for adding additional PCIexpress cards to it. ) has a nice samtec connector array with at least 20 TX and 20 RX pairs on it which we're thinking of using for the XSBI style interface, it has also got a fair number of single ended connections for the slower management stuff as well. We also have available 4 rocket IOs, however these come out via the top PCIexpress motherboard style socket on the board. Our friendly pcb designer laughs at the prospect of doing XAUI over those. It's the kind of laugh that says "go away you firmware man and bother me not with such crazy ideas" I am guessing he's probably correct? Also, anyone played/experienced the Xilinx 10Gig MAC IPCore? Before anyone asks, we're not building a NIC, but a novel high energy physics R&D project for a DAQ system.. Cheers... -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 115902
Marc, The 10G MGTs are all discontinued. Anyone who had alrewady designed them in is supported. But, there are no new orders accepted. The issue was that the rate (10Gbs) was just too demanding for the design and technology. By that, I mean yield of the final chips was unacceptable. All MGTs had to work at all rates, over all temperatures, with the exact same bit settings. 10 Gbs also was a very tiny market segment (only a handful wanted it at all). The hard part was that on any given chip, all MGTs would work well out to 13.5 Gbs, but they each required slightly different bit settings. This required significant soft IP to find the settings for each MGT. It was not considered a viable solution for the mass market. Someday when we harden this IP, and re-design for the next generation, and more than just a few customers require it, 10 Gbs (+) will re-appear. Until then, the separate phy chips are the best solution. AustinArticle: 115903
I'm having trouble getting an IBUFDS to use differential termination,
DIFF_TERM = "TRUE". I'm specifying the pads with:
<SNIP>
-- more code...
-- Generate components for each bit
array_gen : for i in din'high downto din'low generate
begin
-- Generate differential ended input buffer
diffend_gen : if diff_input_g = '1' generate
begin
ibufds_inst : IBUFDS
generic map (
DIFF_TERM => "TRUE",
IOSTANDARD => iostandard_g
)
port map (
I => din(i),
IB => din_n(i),
O => ibuf_out(i)
);
end generate diffend_gen;
-- more code .....
</SNIP>
When I look at the PAR'ed design I'm noticing despite assigning
DIFF_TERM = "TRUE", it's not kept. Note that the above is part of a
separate entity i'm instantiating a few times in the top entity. It
has a generate statement to create IBUFDS, among other ILOGIC parts,
for each bit of my signal. Since I can't get the generic attribute to
be assigned in the vhdl, I'm hoping that assigning it in the UCF will
work. Unfortunately, I have no idea how to do this with generate
statements....
I tried the following, among others...
INST "my_iface_inst/array_gen(*).diffend_gen.ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen<*>.diffend_gen.ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen(0).diffend_gen.ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen<0>.diffend_gen.ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen0.diffend_gen.ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen<0>/diffend_gen/ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen(0)/diffend_gen/ibufds_inst" DIFF_TERM =
TRUE;
INST "my_iface_inst/array_gen0/diffend_gen/ibufds_inst" DIFF_TERM =
TRUE;
but I can't get it to translate.
Any ideas? It's driving me bonkers...
Thanks.
Article: 115904Hi Marc The VSC8479 (Vittesse) chip works fine as weel the Xilinx 10Gig MAC IPCore. We use both. Cheers...Article: 115905
Austin wrote: > The 10G MGTs are all discontinued. > Until then, the separate phy chips are the best solution. That has been my thinking, one of my current candidates is http://www.vitesse.com/products/product.php?number=VSC8479 we're having to wait for our university management to sign the NDA required to get full data sheets, but it looks promising. I am presuming the V4 should cope with the 644Mhz for the XSBI interface? Or is that pushing things a bit too much for a V4 and its best to see if we can get a V5 development board to do this with? Am slightly regretting the decision to say we could do 10Gig easily, our networking people are too obsessed with more and more speed... :) -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 115906
Hi Marc, Virtex-4 is enough for 10Gig but Virtex-5 has interesting feature like OSERDES.Article: 115907
Alain wrote: > The VSC8479 (Vittesse) chip works fine as weel the Xilinx 10Gig MAC > IPCore. We use both. Nice, that is the one I have been looking at.. So knowing someone else has it working makes me slightly more confident I am not totally bull****ing my bosses :) Cheers for that -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 115908
Hi everybody, I tried to recompile under ISE9.1.01i a project which uses MIG1.6. The MIG1.6 controller was generated under ISE8.1.03i. The configuration was the following: > > > FPGA : > Target Device : xc4vlx100-ff1148 > Speed grade : -11 > Options : > HDL : verilog > Synthesis tool : foundation_ise > Module name : mem_interface_top > No of controllers : 1 > > DCI for data : enabled > DCI for address and control: enabled > > /*******************************************************/ > /* Controller 0 */ > /*******************************************************/ > Interface parameters : > Frequency : 210 > Data width : 8 > Depth : 1 > ECC : disabled > > Memory configuration : DDR2 SDRAM:Components > Part number : MT47H64M8BT-37E > > Other Options : > DCM : enabled > Add test bench : enabled > Clocking type : Direct clocking > ClockCapableIO(CC) : enabled > The project runed successfully on board when compiled using ISE8.1.01 but failed to calibrate when compiled with SIE9.1.01i. I tried post-translate simulation and it failed. I understand that in the documentation is stated that the ISE8.1.03i is required but I don't understand why the same RTL code is differently sythesized! this means that a working project on older ISE is not garanteed to work on newers? I made a small search and didn't find any documentation for successfully migrate RTL code to the new ISE. MehdiArticle: 115909
I am surprised that the compiler doesn't error out with you code. The DIFF_TERM in VHDL should be a boolean instead of a string. Can you try assign it to TRUE without double quotes? If it still doesn't work, you can run ngdbuild (Translate in GUI) without DIFF_TERM constraints in UCF. You can then open the ngd file in Floorplanner to get the instance names for your IBUFDS instances. Use the names in Floorplanner to assign DIFF_TERM constraints in the UCF. Cheers, Jim http://home.comcast.net/~jimwu88/tools/ On Feb 24, 1:24 pm, "Brandon Jasionowski" <killerhe...@gmail.com> wrote: > I'm having trouble getting an IBUFDS to use differential termination, > DIFF_TERM = "TRUE". I'm specifying the pads with: > > <SNIP> > -- more code... > > -- Generate components for each bit > array_gen : for i in din'high downto din'low generate > begin > > -- Generate differential ended input buffer > diffend_gen : if diff_input_g = '1' generate > begin > ibufds_inst : IBUFDS > generic map ( > DIFF_TERM => "TRUE", > IOSTANDARD => iostandard_g > ) > port map ( > I => din(i), > IB => din_n(i), > O => ibuf_out(i) > ); > end generate diffend_gen; > > -- more code ..... > </SNIP> > > When I look at the PAR'ed design I'm noticing despite assigning > DIFF_TERM = "TRUE", it's not kept. Note that the above is part of a > separate entity i'm instantiating a few times in the top entity. It > has a generate statement to create IBUFDS, among other ILOGIC parts, > for each bit of my signal. Since I can't get the generic attribute to > be assigned in the vhdl, I'm hoping that assigning it in the UCF will > work. Unfortunately, I have no idea how to do this with generate > statements.... > > I tried the following, among others... > INST "my_iface_inst/array_gen(*).diffend_gen.ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen<*>.diffend_gen.ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen(0).diffend_gen.ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen<0>.diffend_gen.ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen0.diffend_gen.ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen<0>/diffend_gen/ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen(0)/diffend_gen/ibufds_inst" DIFF_TERM = > TRUE; > INST "my_iface_inst/array_gen0/diffend_gen/ibufds_inst" DIFF_TERM = > TRUE; > > but I can't get it to translate. > > Any ideas? It's driving me bonkers... > > Thanks.Article: 115910
Hello, after being bitten by windrvr once again (it did not compile after a kernel upgrade), I decided to see if I could get the Xilinx USB cable and impact working without a kernel module. To achieve this, I have written a wrapper library for impact which maps calls to windrvr to the userspace libusb-library which should be available on all modern linux distributions. With this wrapper I am able to program a XC3S1500 in 2 seconds, which is the same time it takes when using windrvr. The library has been developed and solely tested against impact from ISE Webpack 9.1i SP1 and will very likely not work with older versions (pre 9.1i). The library source can be downloaded at: http://cvs.zerfleddert.de/cgi-bin/viewcvs.cgi/usb-driver.tar.gz?view=tar or browsed at: http://cvs.zerfleddert.de/cgi-bin/viewcvs.cgi/usb-driver/ I have also put a precompiled version (built on Debian Etch) at: http://www.rmdir.de/~michael/xilinx/ Please report back if this library is useful and works for you. Maybe this helps XILINX to decide that they do not need to use windrvr for easy USB access, as most parts of my library are only there to provide a compatible replacement for windrvr functions and are not needed when directly accessing libusb from within an application program. Regards, MichaelArticle: 115911
On Feb 24, 6:32 pm, "Jim Wu" <jimwu88NOOOS...@yahoo.com> wrote: > I am surprised that the compiler doesn't error out with you code. The > DIFF_TERM in VHDL should be a boolean instead of a string. Can you try > assign it to TRUE without double quotes? > > If it still doesn't work, you can run ngdbuild (Translate in GUI) > without DIFF_TERM constraints in UCF. You can then open the ngd file > in Floorplanner to get the instance names for your IBUFDS instances. > Use the names in Floorplanner to assign DIFF_TERM constraints in the > UCF. > > Cheers, > Jimhttp://home.comcast.net/~jimwu88/tools/ > > On Feb 24, 1:24 pm, "Brandon Jasionowski" <killerhe...@gmail.com> > wrote: > > > I'm having trouble getting an IBUFDS to use differential termination, > > DIFF_TERM = "TRUE". I'm specifying the pads with: > > > <SNIP> > > -- more code... > > > -- Generate components for each bit > > array_gen : for i in din'high downto din'low generate > > begin > > > -- Generate differential ended input buffer > > diffend_gen : if diff_input_g = '1' generate > > begin > > ibufds_inst : IBUFDS > > generic map ( > > DIFF_TERM => "TRUE", > > IOSTANDARD => iostandard_g > > ) > > port map ( > > I => din(i), > > IB => din_n(i), > > O => ibuf_out(i) > > ); > > end generate diffend_gen; > > > -- more code ..... > > </SNIP> > > > When I look at the PAR'ed design I'm noticing despite assigning > > DIFF_TERM = "TRUE", it's not kept. Note that the above is part of a > > separate entity i'm instantiating a few times in the top entity. It > > has a generate statement to create IBUFDS, among other ILOGIC parts, > > for each bit of my signal. Since I can't get the generic attribute to > > be assigned in the vhdl, I'm hoping that assigning it in the UCF will > > work. Unfortunately, I have no idea how to do this with generate > > statements.... > > > I tried the following, among others... > > INST "my_iface_inst/array_gen(*).diffend_gen.ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen<*>.diffend_gen.ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen(0).diffend_gen.ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen<0>.diffend_gen.ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen0.diffend_gen.ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen<0>/diffend_gen/ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen(0)/diffend_gen/ibufds_inst" DIFF_TERM = > > TRUE; > > INST "my_iface_inst/array_gen0/diffend_gen/ibufds_inst" DIFF_TERM = > > TRUE; > > > but I can't get it to translate. > > > Any ideas? It's driving me bonkers... > > > Thanks. Oops sorry. i mean to write true, not "true". I pasted the code, which had a generic, but to make it more readable I changed the generic to true but accidentally put quotes. I'll try the floorplanner, thanks.Article: 115912
On 24 Feb 2007 10:24:18 -0800, "Brandon Jasionowski" <killerhertz@gmail.com> wrote: >I'm having trouble getting an IBUFDS to use differential termination, >DIFF_TERM = "TRUE". I'm specifying the pads with: > ><SNIP> > -- more code... > > -- Generate components for each bit > array_gen : for i in din'high downto din'low generate > begin > > -- Generate differential ended input buffer > diffend_gen : if diff_input_g = '1' generate > begin > ibufds_inst : IBUFDS > generic map ( > DIFF_TERM => "TRUE", > IOSTANDARD => iostandard_g > ) > port map ( > I => din(i), > IB => din_n(i), > O => ibuf_out(i) > ); > end generate diffend_gen; Have you tried an ATTRIBUTE rather than a GENERIC? You don't say which synthesis tool you are using, but it is possible that an attribute can make it through when a generic can't. Also, be aware that if "diff_input_g" is defined in a package, XST (6.1 and 7.1 anyway) doesn't read constants defined in external packages when parsing the conditions for a generate statement. I haven't had time to submit a webcase, and since they're on 9.1 now it's probably fixed anyway it's probably been fixed long ago. - BrianArticle: 115913
On 2007-02-25, Michael Gernoth <mike@gernoth.net> wrote: > Please report back if this library is useful and works for you. > Maybe this helps XILINX to decide that they do not need to use windrvr > for easy USB access, as most parts of my library are only there to > provide a compatible replacement for windrvr functions and are not > needed when directly accessing libusb from within an application > program. This sounds excellent, especially if it, as you say, can convince xilinx to use libusb directly :) I'll have to try this tomorrow at work. /AndreasArticle: 115914
Hi all, I am working on making a second level cache for microbalze processor on a ML403 board. This comes in the virtex-4 family. I am looking at 32KB space for cache data. The tag stays in a separate block. The problem that I am having here is that each BRAM primitive is of 2KB, hence i am in an uncomfortable situation in which I would have to use 16 different variables. Is there a way in which I can combine the 16 primitives and get a 32Kb block ram? If so, please specify some details and some links which have information regarding the same. Thanks in advance, BhanuArticle: 115915
Hi all, I am working on making a second level cache for microbalze processor on a ML403 board. This comes in the virtex-4 family. I am looking at 32KB space for cache data. The tag stays in a separate block. The problem that I am having here is that each BRAM primitive is of 2KB, hence i am in an uncomfortable situation in which I would have to use 16 different variables. Is there a way in which I can combine the 16 primitives and get a 32KB block ram? If so, please specify some details and some links which have information regarding the same. Thanks in advance, BhanuArticle: 115916
"Bhanu Chandra" <vbhanu@gmail.com> wrote in message news:1172433285.638808.127220@8g2000cwh.googlegroups.com... > Is there a way in which I can combine the 16 primitives and get a 32Kb > block ram? Yes, write some code (VHDL or Verilog) that instantiates 16 BRAMs and defines how you want them to be connected. > If so, please specify some details and some links which > have information regarding the same. Decode the upper 4 address bits into your 32K address space to use as like a 'chip select' which you would then use to select which one of the 16 BRAMs you want to write to. Those same 4 address bits would also be used as the 'select' input to a 16->1 mux which would be used to select which BRAM data output is the 'read data' output of your 32K memory. Kevin JenningsArticle: 115917
hello I am a student in the faculty of engineering and i am doing my final year project and it is based on System on chip. i us a development board " till now i am using cyclone kit " but i am ordeing now stratix II so it could be cabaple of operating on a higher data rates and honestly till now my design is not so fit and need a large memory bits so i need stratix II my problem lies on bluetooth standard as i want to apply this standard and i did a basic C code for a simple sound application that performs " mod,filtering,demod". I began to study bluetooth standard but i still have a leakage in information so any one could help me on impementation of phy layer or C++ codes of system blocks would be thanked so much thx for reading mailArticle: 115918
> Yes, write some code (VHDL or Verilog) that instantiates 16 BRAMs and > defines how you want them to be connected. > >> If so, please specify some details and some links which >> have information regarding the same. > > Decode the upper 4 address bits into your 32K address space to use as like > a 'chip select' which you would then use to select which one of the 16 > BRAMs you want to write to. > > Those same 4 address bits would also be used as the 'select' input to a > 16->1 mux which would be used to select which BRAM data output is the > 'read data' output of your 32K memory. > or for better timing split the block rams bit wise. For example, you need 16 block rams, so if you want a 32 bit wide memory use the RAMB16_S2_S2 primitive (for dual port) and assign 2 bits of your databus to each memory. The addresses are common. /MikeJ www.fpgaarcade.comArticle: 115919
KJ wrote: > "Bhanu Chandra" <vbhanu@gmail.com> wrote in message > news:1172433285.638808.127220@8g2000cwh.googlegroups.com... > >>Is there a way in which I can combine the 16 primitives and get a 32Kb >>block ram? > > > Decode the upper 4 address bits into your 32K address space to use as like a > 'chip select' which you would then use to select which one of the 16 BRAMs > you want to write to. > > Those same 4 address bits would also be used as the 'select' input to a > 16->1 mux which would be used to select which BRAM data output is the 'read > data' output of your 32K memory. > > Kevin Jennings > > It would be better to set the BRAMs up as 16Kx1, using as many as you need for bits and then a simple 2:1 mux to select between two banks for the 32K size. This eliminates a lot of the external logic by using more of the internal decode. As a result you get considerably better timing and power dissipation. Also, it turns out it is much easier to route because each BRAM has only one read data and one write data rather than the full width of the BRAM.Article: 115920
I am trying to design a system which has a BLOCK RAM on the OPB Bus , interfaced through a OPB_BRAM_IF_CNTLR. I first add an "opb_bram_if_cntlr_0" , and connected it as a slave on the OPB Bus . The system block diagram shows that I have made the slave connection properly, Next i add a "bram_block" and connect the PORT A of the bram_block with the PORT A of the "opb_bram_if_cntlr_0" . Now when i generate the system block diagram, my opb_bram_if_cntrl_0 is no longer on the OPB Bus. !!! More on the console window I get the following error message "Memory controller opb_bram_if_cntlr_0 has a floating bus interface " ... Does any one have any idea , why this could be happening. Thank You VenuArticle: 115921
Hi, Appreciate if anyone could explain me the significance of edge triggering vs level triggering. I know what they are but don't understand the significance except in interrupts. Where do we need edge triggering and where do we need level triggering. Is this applicable only for clock signals? or for data inputs as well? why? Thanks in advance mrArticle: 115922
Edge triggered registers of flip-flops accept data at a well-defined moment, usually right before the rising clock edge. Data levels at all other moments are irrelevant. "level triggered" latches accept data for the whole time that the clock level is active and enabled..The new data is immediately available on the output. Flip-flops and registers are really implemented as two cascaded latches, with opposite clock polarities, but this is of interest only to designers who want to get really deep into the details. Edge-triggered registers and flip-flops are popular because they allow pipelined operation, and allow the output to be fed back to the input, without incurring any race condiditions. Whenever possible, use edge- triggered registers or flip-flops ! Peter Alfke On Feb 25, 10:23 pm, mahenre...@gmail.com wrote: > Hi, > > Appreciate if anyone could explain me the significance of edge > triggering vs level triggering. I know what they are but don't > understand the significance except in interrupts. Where do we need > edge triggering and where do we need level triggering. Is this > applicable only for clock signals? or for data inputs as well? why? > > Thanks in advance > mrArticle: 115923
Geronimo Stempovski wrote: > Ah, okay, what I am actually trying to find out is what makes FR4 act worse > than e.g. teflon at data rates beyond 2,5 Gbps. Is it the loss tangent or > the epsilon r? It is the imaginary part of the dielectric constant. I believe that can be described as a loss tangent, though I haven't done that. > How is the frequency-dependent attenuation physically > describable? Where does the energy go? Heat, ...? Yes, heat. You can consider it as electrical friction. > It was my opinion that > higher frequencies can be transmitted over coax but not over FR4 because of > the geometry. Because in a coax there is (almost) no energy loss because the > TEM wave is "captured" by the outer shield and in a planar setup like > stripline or microstrip there are E-field and H-field lines vanish into the > air environment (or somewhere else...). Therefore I'm trying to design a > coax on a PCB. Am I right with my thoughts, anyway? I don't believe that is true. It may be that coax tends to use better dielectrics. Other than that, even if the wave isn't "captured" as you say, as long as it doesn't find anything else to induce current into, it doesn't contribute to loss. (Well, twisted pair cable is twisted to minimize the radiation. Microstrip isn't twisted. Radiation will be mostly in the plane of the board, and minimized by keeping the board thin.) The very low loss coax cables use a spiral dielectric such that most of the space is air and very little is plastic. There has to be enough material to hold the center conductor in place. The other loss increase with frequency is due to the skin effect, where the current travels in a thin layer on the surface of the wire, increasing the resistance as seen by the current. I believe FR4 is chosen for its thermal and strength properties, and ability to bind to metal, all not normally required by a coax cable dielectric. (And also cost.) -- glenArticle: 115924
Hello, I am kind of new to running linux on my own machine at home and I have chosen to use Ubuntu. I would like to run Xilinx ISE webpack if possible. On my first attempt I couldn't get the windows version to install in Wine, but I'd rather run it natively in linux if possible anyway. I found some page online in french that actually came out somewhat readable when translated to English, describing how to install version 8.1i in Ubuntu 6.06 (which is what I'm using). I tried that, but only got checksum errors when I tried to run the .sh file. Any ideas? Should I switch to CentOS instead or something? Thanks, Steve
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