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
Antti wrote: > Mike Harrison schrieb: > > > On 27 Sep 2006 02:03:55 -0700, "Antti" <Antti.Lukats@xilant.com> wrote: > > > > >Dolphin schrieb: > > > > > >> Hello, > > >> > > >> I am considering to use Spartan 3 devices on our new board. Xilinx > > >> recommends XCF04S and XCF08P devices for configuration of a Spartan 3 > > >> 1000. Does anybody know other and cheaper configuration solutions for > > >> this FPGA? > > >> > > >> thanks and best regards, > > >> Dolphin > > >6 (or 8 pin) micro (costs 0.60 USD?) + SPI flash > > or 9536XL CPLD if you need more speed, not much more expensive > > the speed of the micro is ir-relevant, the FPGA generates the CCLK! > thats the beaty, cheapest smallest micro is enough, you only pushin > the read command, and let the FPGA todo the rest. Better make sure the SPI device has a continuous array read command. If you need to read per page, this technique won't work. By the way this sounds like you would need a little bit of extra logic to mux CCLK to the flash? Or were you supposing that the micro would push the command while the CCLK was free-running to the flash? Even at the startup CCLK speed that might require something a little faster than the cheapest smallest micro? > > the bitstream can embedded CCLK frequency to swithc to higher > configuration clock. > > XC9536 are cheap too, but even in smallest package they are rather > large compared > to tiny micros in QFN 11 or SOT package > > AnttiArticle: 109476
Falk Brunner schrieb: > Antti schrieb: > > > well the OP wanted S3 so thats not an option, > > Is it? Says who? I did not hear anything from the OP that prevents the > use of a S3E. There are many ways to skin a cat. ;-) > > Regardas > Falk OP wanted solution for S3, not for S3e for S3e the SPI flash is obvious, and I bet Xilinx FAE would have suggested it, so I must assume that the S3e wasnt an option and solution was really required for S3 equally well I could say that solution is to use Cyclone or LatticeEC PFGA's as both support SPI loading and are comparable in size to Spartan-3, eg larger than larger device in Spartan3e AnttiArticle: 109477
Gabor schrieb: > Antti wrote: > > Mike Harrison schrieb: > > > > > On 27 Sep 2006 02:03:55 -0700, "Antti" <Antti.Lukats@xilant.com> wrote: > > > > > > >Dolphin schrieb: > > > > > > > >> Hello, > > > >> > > > >> I am considering to use Spartan 3 devices on our new board. Xilinx > > > >> recommends XCF04S and XCF08P devices for configuration of a Spartan 3 > > > >> 1000. Does anybody know other and cheaper configuration solutions for > > > >> this FPGA? > > > >> > > > >> thanks and best regards, > > > >> Dolphin > > > >6 (or 8 pin) micro (costs 0.60 USD?) + SPI flash > > > or 9536XL CPLD if you need more speed, not much more expensive > > > > the speed of the micro is ir-relevant, the FPGA generates the CCLK! > > thats the beaty, cheapest smallest micro is enough, you only pushin > > the read command, and let the FPGA todo the rest. > > Better make sure the SPI device has a continuous array read > command. If you need to read per page, this technique won't > work. By the way this sounds like you would need a little bit > of extra logic to mux CCLK to the flash? Or were you supposing > that the micro would push the command while the CCLK was > free-running to the flash? Even at the startup CCLK speed that > might require something a little faster than the cheapest smallest > micro? > > > > > the bitstream can embedded CCLK frequency to swithc to higher > > configuration clock. > > > > XC9536 are cheap too, but even in smallest package they are rather > > large compared > > to tiny micros in QFN 11 or SOT package > > > > Antti the micro holds PROG_B active so CCLK is tristated. it takes a few clock cycles of the MCU to shift in the array read and then all it has to be done is to make release the PROG_B the FPGA does the rest at config speed programmed into the BIT file AnttiArticle: 109478
I use Aurora v2.4 and in my case I have no problem with the constraint you mention. My understanding is that the keep_hierarchy constraint is there to make sure that the flops to be constrained in the ucf file stay whithin a known hierarchy path. So your 2nd post is strange. I would have thought that the opposite would happen. You can use fpga editor to see what is the correct hierarchy to target your flops in the ucf. You could also try to add a *, as in: INST aurora_module_i/lane_0_phase_align_i/*phase_align_flops_r* AREA_GROUP="PHASE_ALIGN_0_GRP"; Patrick INST aurora_module_i/lane_0_phase_align_i/phase_align_flops_r* AREA_GROUP="PHASE_ALIGN_0_GRP"; AREA_GROUP "PHASE_ALIGN_0_GRP" RANGE=SLICE_X14Y72:SLICE_X15Y73; Roger wrote: > "Roger" <enquiries@rwconcepts.co.uk> wrote in message news:... > > > > "Roger" <enquiries@rwconcepts.co.uk> wrote in message > > news:4516e3e1$0$3616$ed2e19e4@ptn-nntp-reader04.plus.net... > >> I'm having trouble getting some lines in a UCF file to be accepted by > >> ISE. The lines are: > >> > >> NET Inst_rio_fo2_top/aurora_module_i/lane_0_mgt_i/RXRECCLK PERIOD=6.4 ns; > >> NET Inst_rio_fo2_top/user_clk_i PERIOD = 6.4 ns HIGH 50 %; > >> INST > >> Inst_rio_fo2_top/aurora_module_i/lane_0_phase_align_i/phase_align_flops_r* > >> AREA_GROUP="PHASE_ALIGN_FO2_GRP"; > >> AREA_GROUP "PHASE_ALIGN_FO2_GRP" RANGE=SLICE_X26Y72:SLICE_X27Y73; > >> INST Inst_rio_fo2_top/aurora_module_i/lane_0_mgt_i LOC=GT_X1Y1; > >> > >> which is for an Aurora core on a 2VP7. Much of this is copied from the > >> sample Aurora stuff generated by the Core Generator. Has anyone else had > >> any issues with this or can anyone see anything obvious. The error occurs > >> on the > >> > >> INST > >> Inst_rio_fo2_top/aurora_module_i/lane_0_phase_align_i/phase_align_flops_r* > >> AREA_GROUP="PHASE_ALIGN_FO2_GRP"; > >> > >> line when it's claimed it could not find the instance of the phase align > >> flops but which are definitely there. > >> > >> TIA, > >> > >> Rog. > >> > > > It seems that the lines in lane_0_phase_align_i (phase_align.vhd) : > attribute KEEP_HIERARCHY:string; > attribute KEEP_HIERARCHY of RTL: architecture is "true"; > are the source of trouble. If these are comented, the Translate process runs > OK. Does anyone know what's going on here? > > Thanks, > > Rog.Article: 109479
Antti wrote: > Falk Brunner schrieb: > > > Antti schrieb: > > > > > well the OP wanted S3 so thats not an option, > > > > Is it? Says who? I did not hear anything from the OP that prevents the > > use of a S3E. There are many ways to skin a cat. ;-) > > > > Regardas > > Falk > > OP wanted solution for S3, not for S3e > for S3e the SPI flash is obvious, and I bet Xilinx FAE would have > suggested it, so I must assume that the S3e wasnt an option > and solution was really required for S3 > > equally well I could say that solution is to use Cyclone or LatticeEC > PFGA's > as both support SPI loading and are comparable in size to Spartan-3, eg > larger than larger device in Spartan3e Do the S3e parts have the same issue with the overly stiff pullups that the S3 parts have? I'm not sure if they are going to fix that in the S3a parts or not.Article: 109480
u_stadler@yahoo.de schrieb: Hi, > i have a digilent spartan 3e board (rev. D) and i'm trying to get the > ethernet going. i'm using microblaze/ethernetlite as hardware. > xilkenerl an lwip as software. everything seems to initialize fine but > when i try to connect via telnet it takes a long time to connect and > when i ping the board i have a lot of packet loss. > > i read on the xilinx webpage that in edk version 8.2 it is possible to > generate sample ethernet code. since i only have the version 8.1 i > really would appriciate it if somebody could do this for me and send me > the code / project if possible. > > does anybody have some other ideas what could be wrong perhaps? The Xilinx-Ethernet core has some limitations regarding the clock speed. 100 MBit operation requires the OPB clock to be at least 65 MHz. To use 10 MBit link speed 6,5 MHz is sufficient. You should also check your half-/full-duplex setting. I have experienced problems using autonegotiation with the uClinux running on an ML405. AndreasArticle: 109481
Several months ago, I opened a WebCase with Xilinx regarding packing the OE registers into an IOB. I sent example cases showing how the tools failed to use the OE registers when infering logic. It took a while to convince the Xilinx "support" person that the tools were doing a very poor job on a very obvious and desireable IOB register packing operation. I know that in previous versions of ISE, you needed to have all the IOB logic in one level of hierarchy if you wanted any chance of automatically usin ghte IOB registers. John Providenza David R Brooks wrote: > Patrick Dubois wrote: > > Hello, > > > > I know that this has been discussed here a few times but I still can't > > find a definitive answer so here we go again... > > > > What is the best way (with Xilinx flow) to ensure that registers are > > packed into IOB? In my case I want three registers to be packed into > > the IOB for a bidirectionnal signal (in, out and oe). > > > > The registers in question are buried in a vhdl module two hierchical > > levels down. This module is synthesized separately into a ngc file (as > > most of my other modules) to create an "incremental" flow. I'm not > > using xst own incremental flow however (i.e. I'm not using a xcf file > > with -incremental_synthesis flags). > > > > To make matters a little more difficult, I would really like to keep > > the hierarchy as it makes it much easier to debug with Chipscope. > > > > I read quite a bit about the issue and the standard tricks seem to be: > > 1- Use the IOB = "true" constraint in the HDL code for the registers > > 2- Use the flag -iob true for xst (redundant with #1) > > 3- Use -pr b at the map stage > > 4- Duplicate the oe registers and use equivalent_register_removal = > > "NO" to prevent xst from optimizing them away > > 5- Make sure that the fanout of output registers and fanin of input > > registers is 1. > > 6- Run map with the option -ignore_keep_hierarchy to flatten the > > design. > > 7- From Xilinx WP231: When using hierarchy: "Place all I/O components > > including any instantiated I/O buffers, registers, DDR circuitry, > > SerDes, or delay elements on the top-level of the design. If it is not > > possible to place them on the top-level, ensure that they are all > > contained within a single hierarchy." > > > > Now I followed the above tricks except #7. For the moment I'd be happy > > even if I don't keep hierarchy. The best I could acheive so far is that > > the input registers are in the IOB. The out and oe registers however > > are not. > > > > Now maybe if I followed trick #7, I could make it work but it seems > > very ugly to me. I don't want logic on the top level that is related to > > a sub module two levels down. Furthermore, using the flag > > ignore_keep_hierarchy at the map stage should produce the same result, > > shouldn't it? > > > > Any suggestions? > > > Your #7 may be the magic key. From the "Virtex4 Synthesis & Simulation > Design Guide": > > Resources that can be shared should be on the same level of hierarchy. If these resources are > > not on the same level of hierarchy, the synthesis tool cannot determine if these resources > > should be shared. > In some sense, IOB packing is a kind of resource sharing. So the packer > probably won't work across hierarchy boundaries.Article: 109482
Hello, I've got a Xilinx Virtex 4 FPGA and would like to address the onboard DDR-SDRAM. I've found out that I can instantiate special DDR-IO flip flops by hand (and found an example in the ISE-Webpack documentation). But I'm still not sure how to address the DDR-SDRAM best, especially I don't know how to handle the DQS-Signal of the DDR-SDRAM, because I need a sensitivity on both edges. Perhaps someone can even help me with a short example (VHDL preferred). Thanks in advance, ThomasArticle: 109483
Hello, In my future design I could win a lot of pins if I could drive a bus at 160MHz. Because of bank restrictions and because this bus is connected to a CPLD, I will have to use LVTTL. Has anybody tried driving a bus in LVTTL at 160MHz? I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has LVDS CPLDs but only the large CPLDs support LVDS inputs. I am afraid that this bus will have a lot of EMI/EMC problems. What do you think of it, should series termination be adequate to limit the EMI/EMC problems? best regards, DolphinArticle: 109484
Hello, It is correct that S3E is easier to configure using an SPI flash. Because S3 devices have more IOs than S3E I have to use S3 for this design. Thanks for the info, DolphinArticle: 109485
Simulate it. Hyperlynx is your friend! HTH, Syms. "Dolphin" <Karel.Deprez@gemidis.be> wrote in message news:1159368842.453549.244660@b28g2000cwb.googlegroups.com... > Hello, > > In my future design I could win a lot of pins if I could drive a bus at > 160MHz. Because of bank restrictions and because this bus is connected > to a CPLD, I will have to use LVTTL. > Has anybody tried driving a bus in LVTTL at 160MHz? > > I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has > LVDS CPLDs but only the large CPLDs support LVDS inputs. > > I am afraid that this bus will have a lot of EMI/EMC problems. What do > you think of it, should series termination be adequate to limit the > EMI/EMC problems? > > best regards, > Dolphin >Article: 109486
Vasanth Asokan schrieb: Hi, > Bug in saving MSR from within system calls. Sample patch attached that fixes > the problem. thanks for the fast supply of the patch. Everything works fine now. AndreasArticle: 109487
Thomas wrote: > Hello, > I've got a Xilinx Virtex 4 FPGA and would like to address the onboard > DDR-SDRAM. > I've found out that I can instantiate special DDR-IO flip flops by hand > (and found an example in the ISE-Webpack documentation). > But I'm still not sure how to address the DDR-SDRAM best, especially I > don't know how to handle the DQS-Signal of the DDR-SDRAM, because I need > a sensitivity on both edges. > > Perhaps someone can even help me with a short example (VHDL preferred). Did you ever work with FPGA and DDR before ? From your post I'd recommend just take an existing DDR controller and don't try to do one yourself. Even doing that is sometimes tricky ... SylvainArticle: 109488
rickman wrote: > The board that Lattice sells come with virtually no docs, so I don't > even consider that a product. I found one from a European company MSC, > but it is not clear if the docs are in English or not. They have web > pages in both English and German, but the PDF advertisement is in > German only - CPLD-Eval-Board. Anyone know if this product is > documented in English? > > Are there any other eval boards out there for the ispMACH4000 parts? The board you are talking about is a very simple board. So the only documentation we have is a board schematic. Please send your email address to my office email: mgl@msc-ge.com On next Monday I can send you the schematic. Stay in contact. Regards Matthias Glattfelder Productmanager Programmable Logic Lattice MSC Vertriebs GmbHArticle: 109489
Hi all, I am implementing a microblaze processor in a subdesign in a Virtex4 component (ISE v7.1 sp3, EDK v7.1 sp2). The microblaze is using the internal BRAMS as instuction and data memory. The program is increasing and becomes more than 64kByte. The blockram controller does only support 64kByte size of memory. The solution for that is implementing two bram controllers in a continous address-space (bram ctrl 1 from 0x000 to 0x00ffff and bram ctrl 2 from 0x010000 to 0x01ffff). If I compile the code the compiler gives no error on the code size, but I got one text block of more than 64kByte. If I insert the design in the bitstream with Data2Mem I got an error, because it is not possible to fit the textblock in one of the address spaces defined in the bmm file. It would be a solution to split the textblock in two parts. I have found the instructions for writing a LinkerScript for doing that. The only problem I have is to find the place where the object files of my code are temporary stored. The code is built with the mb-gcc cross compiler. Is there anyone out there who is doing the same kind of implementation ? Could someone help me with some kind of documentation about the mb-gcc ? Thanks in advance, Bart De ZwaefArticle: 109490
Symon wrote: > "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message > news:mdjjh29ufai6ikj1045j31vrh9h9726onm@4ax.com... > > On 27 Sep 2006 01:46:33 +0200, "Symon" <symon_brewer@hotmail.com> > > wrote: > > > >>i THINK IT SHOULD BE A m=F6BIUS STRIP fpga. sPECIFICALLY, A fpga SHAPED= LIKE > >>A > >>m=F6BIUS STRIP. tO BE PRECISE, A TWO DIMENSIONAL kLEIN BOTTLE. i URGE Y= OU TO > >>UPDATE YOUR UNDERSTANDING OF MY CLEAR AND ACCCURATE ADVICE. > >>hth< YOURS 7TC< sYMSX > > > > I have already patented this idea, whatever it is. Please refer to > > Pat. 23764598, "Eine Kleine Bottle/Nachtmusik." > > > > Royalty payments are of course welcome. > > > > Bob Perlman > > Cambrian Design Works > > > Mr. Bob, > > I didnt like your patent: to me seems that you want to revenge from someo= ne. > > On examining it, although it seems that you know the expression of letters > when addressing in the behavioral life, i noticed that your patent only is > covering the clockwise twisted M=F6bius strip and this is not acceptable!= I > have now patented the anti-clockwise phenotype (Pat. 89546732) and i igno= re > the field where you come from! My idea will dominate the culture south of > the equator. > > Hope you be more chiral and understanding when patenting your non-orienta= ble > ideas, otherwise your inventions are not interesting and will be rejected! > > may you tell me how can i post my cv online? > > Thanks! Stop this already, some of us are not going to get much work done today if you keep this up. Now I have to go clean myself up:) John Jakson transputer guyArticle: 109491
David Ashley wrote: > Speaking of which, here's a nobel prize winning idea. > Assuming the problem of protein folding is part of NP > complete, all you'd have to do is construct a DNA > sequence that encodes for a protein, and the protein > itself is equivalent to some OTHER NP problem you > want to solve. So you let the protein go and fold however > it wants to, and then you look at how it's folded, and you > have your answer. So you've managed to get the universe > to work for you. :) Not a particularly new idea, I'm afraid. The problem is that the protein corresponding to a hard problem will take nearly *forever* to fold. It is not true that an arbitrary protein sequence will quickly fold into a stable structure that is the same each time. In fact, most will *not* do that. Biological proteins do (mostly), but they were selected for that. Ralph HartleyArticle: 109492
"rickman" <gnuarm@gmail.com> wrote in message news:1159365978.100646.5140@i42g2000cwa.googlegroups.com... > > Do the S3e parts have the same issue with the overly stiff pullups that > the S3 parts have? I'm not sure if they are going to fix that in the > S3a parts or not. It was fixed, indeed. The pullups on the S3s were pretty stiff. Things are back toward expectations now with the S3E. I would expect the S3A to follow S3E's lead.Article: 109493
I'd recommend searching the Xilinx APP notes for DRAM controllers; you might get good hits just by searching for "DQS." There's a bit of literature already there. "Thomas" <"Thomas.10.Hinz"@spamgourmet.com> wrote in message news:4nvh7nFbvulcU1@news.dfncis.de... > Hello, > I've got a Xilinx Virtex 4 FPGA and would like to address the onboard > DDR-SDRAM. > I've found out that I can instantiate special DDR-IO flip flops by hand > (and found an example in the ISE-Webpack documentation). > But I'm still not sure how to address the DDR-SDRAM best, especially I > don't know how to handle the DQS-Signal of the DDR-SDRAM, because I need a > sensitivity on both edges. > > Perhaps someone can even help me with a short example (VHDL preferred). > > Thanks in advance, > > ThomasArticle: 109494
zeeman_be schrieb:
> Hi all,
>
> I am implementing a microblaze processor in a subdesign in a Virtex4
> component (ISE v7.1 sp3, EDK v7.1 sp2).
> The microblaze is using the internal BRAMS as instuction and data
> memory.
>
> The program is increasing and becomes more than 64kByte. The blockram
> controller does only support 64kByte size of memory. The solution for
> that is implementing two bram controllers in a continous address-space
> (bram ctrl 1 from 0x000 to 0x00ffff and bram ctrl 2 from 0x010000 to
> 0x01ffff). If I compile the code the compiler gives no error on the
> code size, but I got one text block of more than 64kByte.
>
> If I insert the design in the bitstream with Data2Mem I got an error,
> because it is not possible to fit the textblock in one of the address
> spaces defined in the bmm file.
>
> It would be a solution to split the textblock in two parts. I have
> found the instructions for writing a LinkerScript for doing that. The
> only problem I have is to find the place where the object files of my
> code are temporary stored.
>
> The code is built with the mb-gcc cross compiler.
>
> Is there anyone out there who is doing the same kind of implementation
> ?
> Could someone help me with some kind of documentation about the mb-gcc
> ?
>
> Thanks in advance,
> Bart De Zwaef
Hi Bart,
if it doesnt work with old-old EDK versions then you just need to
upgrade. I have verified that continous memory block loading over 64kb
boundaries work in EDK 8.2 SP1 - as part of work with
www.microfpga.com
one of my test targets has 192 KB internal memory and data2mem doesnt
complain at all, just initializes the bit file
did you verify the BMM, does it have
ADDRESS_MAP microblaze_0 MICROBLAZE 100
///////////////////////////////////////////////////////////////////////////////
//
// Processor 'microblaze_0' address space 'bram_combined'
0x00000000:0x0002FFFF (192 KB).
something alike?
this is from working design that CAN init more than 64kb junks
Antti
Article: 109495> Use DCM to get clock below 100MHz you should be able to run at some 75MHz or > maye 83Mhz > but hardly at 100MHz > of course the UART baud settings have to match, but I think since 8.2 EDK is > able to verify and warn > if uart baud is wrong > > also note that 8.2 may get better timing, but still hardly 100MHz sysclock > for S3e > > Antti Thank you for the responses. I will give this a shot. Did I miss something in the data sheets/app notes though? I wasn't aware that the S3E had such limitiations on the upper bound for the sysclock on uBlaze processors. Secondly, I have a licensed version of EDK 8.2, but was going to wait until my next project to upgrade my development platform (ISE, EDK, ChipScope, etc.). Do you advise upgrading EDK sooner rather than later? ThanksArticle: 109496
mjackson schrieb: > > Use DCM to get clock below 100MHz you should be able to run at some 75MHz or > > maye 83Mhz > > but hardly at 100MHz > > of course the UART baud settings have to match, but I think since 8.2 EDK is > > able to verify and warn > > if uart baud is wrong > > > > also note that 8.2 may get better timing, but still hardly 100MHz sysclock > > for S3e > > > > Antti > > Thank you for the responses. I will give this a shot. > > Did I miss something in the data sheets/app notes though? I wasn't > aware that the S3E had such limitiations on the upper bound for the > sysclock on uBlaze processors. > > Secondly, I have a licensed version of EDK 8.2, but was going to wait > until my next project to upgrade my development platform (ISE, EDK, > ChipScope, etc.). Do you advise upgrading EDK sooner rather than later? > > Thanks there is no direct upper bound freq limitations its rather complicate to give such numbers actually. but as thumb guess if the system is not optimized for Xilinx marketing to give absolute total max sysclock then the system in S3e would have more chance to pass timing on sysclock below 100MHz but, again it all depens what IP cores you have in and how you apply constraints and if you run xplorer script and multipass PAR, etc.. Its also hard to get 100Mhz on Virtex-4 (Xilinx advertizes 200MHz max MicroBlaze clock for ver 4) so timing trouble on realworld microblaze design in S3e at 100Mhz are just to be expected. you should try EDK 8.2 and MB5 it has improved pipeline that should allow higher clocks, also it can run xplorer script on XPS system AnttiArticle: 109497
Thanks David. #7 was indeed the key. Fortunately I didn't have to bring the registers all the way to the top level. All that was needed was to keep everything on the same hierarchical level. Another trick that I needed is that when synthesizing the top_level, one has to let xst absorb the ngc submodule by using -read_cores optimize (just "yes" won't work) and -sd pointing to the right path. It doesn't work otherwise. Unfortunately this makes the synthesis MUCH slower. Another observation is that #6 is not needed after all. Now I'm going to try to keep the hierarchy. Hopefully I won't have to bring the registers to the top... Patrick David R Brooks wrote: > Your #7 may be the magic key. From the "Virtex4 Synthesis & Simulation > Design Guide": > > Resources that can be shared should be on the same level of hierarchy. If these resources are > > not on the same level of hierarchy, the synthesis tool cannot determine if these resources > > should be shared. > In some sense, IOB packing is a kind of resource sharing. So the packer > probably won't work across hierarchy boundaries.Article: 109498
Mark McDougall <markm@vl.com.au> wrote: >Adnan wrote: > >> I am a final year student and working on my senior design project. I >> need PCI Master core and unfortunately I cannot buy any licensed core >> because of their high price. I have seen opencores.org PCI bridge but >> it has few problems >> 1. Its test bench is too complex to understand. I was expecting some >> black box sort of interface. >> 2. Its driver is written in linux, but I have developed my software >> part in MS Visual C-6, soI need windows driver. > >1. If you spent a little more time trying to understand how it works, >you'll see that it's not that complex at all. It's simply that the tests >are quite comprehensive and hence covers quite a large number of cases. > >In fact, we stripped out the 'core' functions of the testbench to create >a library of routines that allowed us to write testbench scripts for >higher-level PCI functionality and there really isn't a lot of code in >there. > >2. As Kolja said differently, there's no such thing as an "opencores PCI >driver". The core out-of-the-box does absolutely *nothing* useful other >than appear as a PCI bridge to bios and/or low-level OS probing routines. > >It's not until you add peripherals to the back end that you require a >"driver" and this is dependent not on the bridge itself but your chosen >configuration of PCI space and the peripherals you implement. Just a small addition: it is not difficult to mimic a 16550 UART. If you buy a 16550 based PCI serial interface card and set your PCI card to the same ID, the driver for the PCI serial card will also recognize and work with your board. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 109499
Has anyone had any luck importing the EDIF output of the " MAX+PLUS II Advanced Synthesis Tool" into Max Plus II? I have a bunch of VHDL modules, and I need to tie them with a megawizard output file at the top level, so I thought it would be easier to do that part graphicly, and create a symbol for my top-level VHDL design. I've been getting compile errors in the EDIF that don't make sense, like "can't open file *.lmf" and "can't find design file 's_dffe'". Does anyone have any suggestions? I'm working on a design targeted at board we designed and built in-house about 5 or so years ago, and it has a variant of a Flex10KE that isn't supported by Quartus II. Someone at Altera suggested trying to target a simular device, and changing the name in the programming file, which *might* work, but I want to get at least this part of the design working in Max Plus II as well, so if it dosen't work from Quartus I can tell if it's a design bug, or a tools issue. Everyone else here has, as far as I know, worked with only block diagram designs in Max Plus II, so they haven't had this issue.
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