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 and thanks for the pointers. well the SD Card support is not that easy a combined MMC-SD card IP-Core would be at least 50 PLD Cells (MMC only is 21 Macrocells). I know all the spec and differencies, I just never got enough time to add SD support. One option could of course be using SPI mode, but thats not so nice. When MMC-SD Card is left in MMC mode then the FPGA can after config use its own MMC Core to communicate with the Card, if the config core initializes SPI mode then FPGA should also access the card in SPI mode. AnttiArticle: 77276
There is a PCMCIA to Parallel-Port adapter available: QUATECH SPP-100, Single parallel port PCMCIA card for about 160,00 Euro, it worked well on several PC´s... And for just configuring - have a look at the FTDI chips and bit-bang app-notes: http://www.ftdichip.com with best regards, Peter Seng ############################# SENG digitale Systeme GmbH Im Bruckwasen 35 D 73037 Goeppingen Germany tel +49 7161 75245 fax +49 7161 72965 eMail p.seng@seng.de net http://www.seng.de ############################# "Alan Randomdude" <randomdude@gmail.com> schrieb im Newsbeitrag news:d2b05bc6.0412261533.58ba2077@posting.google.com... > Hi there. > > I've been programming using a parallel byteBlaster-type lead, > attatched to an old 486, via a network connection to my laptop. This > is because my laptop is devoid of parallel or serial ports (oh, the > foresight). I hear I can't use USB to Parallel adaptors (arse!) and I > can't imagine me finding a pcmcia parallel adaptor (though I could > make one..?) and looking on alteras site reveals they want about > £150/$300usd for their USB baster. Nads to that - Anyone know of > anywhere selling a usb programmer for sensible (hobbyist) amounts? Or > a way out of my situation? Thanks. > > -Alan / randomdudeArticle: 77277
Peter Seng <NOSPAM@seng.de> wrote: > There is a PCMCIA to Parallel-Port adapter available: > QUATECH SPP-100, > Single parallel port PCMCIA card for about 160,00 Euro, it worked well on > several PC?s... > And for just configuring - have a look at the FTDI chips and bit-bang > app-notes: > http://www.ftdichip.com The FT2232 has a dedicated serial engine to generate JTAG/SPI/I2C. However I have not seen an open project for JTASG interface to use this chip. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 77278
What you want is only the last step of a merge sort. You still need to need to implement it in VHDL (or whatever HDL you choose), but here is a pointer that may help you. http://www-unix.mcs.anl.gov/dbpp/text/node127.html -- SystemVerilog DPI tutorial on Project VeriPage: http://www.project-veripage.com/dpi_tutorial_1.php For subscribing to Project VeriPage mailing list: <URL: http://www.project-veripage.com/list/?p=subscribe&id=1>Article: 77279
I was under the impression that SD was designed to be a superset of MMC, e.g. that if you plugged one into an MMC socket the equipment would read it in that mode. That sounds sensible but the SD designers may not have been. Is it that SD equipment can read both cards but MMC equipment can only read MMC? Your project is very welcome, those configuration memories are way too expensive. I wonder how hard it would be to have a small micro (e.g. AVR 2313?) reading a FAT-formatted SD card to get a fixed named file (e.g. FPGA_CFG.ROM) to load the FPGA? That would allow ordinary PC software to just copy the file across, rather than have to write to a linear sequence of blocks. As a useful bonus, the SD card after FPGA-loading might be handed over to the target micro for normal memory card duties. So long as it doesn't mess around with the FPGA_CFG.ROM file of course! The target micro may even be the same as the loader micro. I hear FAT handling is non-trivial, so perhaps having written it for the loader micro the loader could also be useful as an I/O slave. Might save a lot of porting work.Article: 77280
highwayismyway wrote:
> Some of the my companies IP cores source has
> disappeared and thought maybe someone here could help me out at
> recovering the missing source. Does anyone know of any altera
> dissassembler or decompiler for the SOF file? I'm not particularly
> concerned if the the output is VHDL, verilog, or even AHDL.
It is possible to recover a primitive netlist
of the entire design. However, picking out IP
cores for reuse is not possible.
This situation illustrates the downside of keeping
source code on a single machine.
A disk drive drive can die or take to the highway
at any time without advance notice.
-- Mike Treseler
Article: 77281
Kryten wrote:
> I wonder how hard it would be to have a small micro (e.g. AVR 2313?) reading
> a FAT-formatted SD card to get a fixed named file (e.g. FPGA_CFG.ROM) to
> load the FPGA?
Flash file systems are available to do this
if your micro can compile C code.
Vendor-specific versions are sometimes free.
-- Mike Treseler
Article: 77282Hi all, i'm first time approch with fpga, i have xilinx ise and edk 6.3i version. With XPS I have create a new project with project builder on spartan 3 starter development kit. When i go to compile the project the programm given back this error: Performing System level DRCs on properties... INFO:MDT - List of peripherals addressable from processor instance microblaze_0 : - dlmb_cntlr - ilmb_cntlr - debug_module - Generic_GPIO Building Directory Structure for microblaze_0 cd: Too many arguments. ERROR:MDT - Failed to remove G:\Documents and Settings\risc\microblaze_0\libsrc\. LibGen Done. make: *** [microblaze_0/lib/libxil.a] Error 2 Done. Have you an idea to resolve this problem? thanks Regards R!SCArticle: 77283
Mark, If you still have a simulation library for it, you might find it in one form or another in there. For modelsim, these are typically a directory named work. Cheers, Jim > I realize that this might not be appropriate question for this group, > but considering the level of knowledge I thought I would see if anyone > knows much about recovering lost verilog code from a .sof altera > Quartus FPGA binary? Some of the my companies IP cores source has > disappeared and thought maybe someone here could help me out at > recovering the missing source. Does anyone know of any altera > dissassembler or decompiler for the SOF file? I'm not particularly > concerned if the the output is VHDL, verilog, or even AHDL. Because of > the ethics of reverse engineering I would be willing to present anyone > with the evidence they might need to verify that my company has all > copyrights and ownership of the .sof Im asking to derive the source > code. Any thoughts how I can do this? > > Mark S. > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 77284
Hi Sylvain, Just saw your message; Hotmail relegated your email to my Spam folder! Anyway, I'm working away in the UK presently, I'll be back at my desk later this week, when I can give you more detail. I can say that the spacing between layers 1 and 2 is small. It has to be for the laser drill to work. IIRC, it's only 2 mil / 2 thousands of an inch. This means that layer 1's 'reference plane' is of course layer 3, but it's not much further away from layer 1 than layer 2. The consequences are, I suppose, that, for controlled impedance traces, layer 1 tracks have to be a little thicker. I generally keep my controlled impedance traces on layer2. Or very short so it doesn't matter; remember the laser vias enable you to get ICs a lot closer together than you would otherwise be able to do! Of course, if you're trying to build accurate controlled impedance traces on layer 1, you don't want to be putting a lot of layer 2 traces underneath these layer 1 traces. On the other hand, occasional 90 degree crossings aren't gonna be a problem. Mentor's Hyperlynx is a great tool for checking this sort of stuff out. Cheers, Syms. "Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> wrote in message news:41D6B1AF.2010705@reducespam.com... > Hello Symon, > > > I'd like more informations about the stackup you use, what are the thickness of the layers/prepreg ? > What are the consequences of not having the top layer referenced to a 'near' plane ? > > > Thanks, > > Sylvain > > > PS: Note I wrote both to the news group and bcc to you to make sure you see this answer, > as the topic is not recent. > > > Symon wrote: > > All, > > > > After reading and contributing to a few interesting threads recently about > > PCBs for FPGA designs, I thought I'd post about the technology I've been > > using for the past 3-4 years. My job involves getting a lot of high density > > circuitry into a small space, and so awhile back I decided to use microvias > > (laser drilled vias) to pack more stuff onto my boards. The surprising thing > > was that the boards worked out cheaper for my application than if I hadn't > > used this method. > > > > I'll explain why, but you might first want to download the picture at > > > > http://www.fpga-faq.org/caf_pics/layer_1_2.gif > > > > My stackup is ten layers, like this:- > > > > 1) signal > > > > 2) signal > > > > 3) ground > > > > 4) signal > > > > 5) signal > > > > 6) ground > > > > 7) signal > > > > 8) signal > > > > 9) ground > > > > 10) signal > > > > > > > > There are laser drilled microvias between layers 1 and 2. The only other > > vias are through vias, i.e. from layer 1 through all layers to layer 10. > > This means there's still only one mechanical drilling process during > > manufacture. What you can see in the picture you downloaded is how to route > > out all but four of the signal pins on banks 2 and 3 of a V2PRO in a FG676 > > package without using any through vias, just microvias between the two > > layers, blue and light green. The track and gap distance is 4mils or 100um. > > With this technology you can go 8 rows deep on a 1mm pitch BGA without using > > through vias. > > > > In no particular order, here are the advantages. > > > > It's no problem at all to put microvias in a pad. The microvia is just a > > 2mil deep pit that fills with solder, unlike a through via which must be > > plugged to stop the solder wicking away. > > > > You can use fewer signal layers because the signal paths out from the FPGA > > aren't baulked by through vias. > > > > You can use fewer (or no) power layers because it's possible to fit a lot of > > bypass caps on the back side of the board from the FPGA, with through vias > > direct from these to the FPGA power balls. (In the picture you can see the > > ground (green) balls and Vcco (yellow) balls. By the time this board went > > out, there were two through vias for each power ball.) With a conventional > > board, the through vias don't leave space on the backside to fit (m)any > > caps. > > > > You get to have a decent ground plane(s) for your BGA devices, not one > > turned into Swiss cheese by a myriad through vias. Bye-bye ground bounce. > > > > You gain board area all over the back side of the board simply because > > there's less space used by the vias from the topside. > > > > Compared to a through via, the SI of a microvia is much better. After all, > > it's only 1/30th the length of a through via. > > > > The components can be closer together, reducing SI issues. > > > > > > > > I always follow some rules when routing FPGAs this way. Like these:- > > > > Draw lines from the four corner balls to the very centre of the part. Don't > > let any layer 1 or 2 traces cross these lines, it always seems to screw > > things up. > > > > Be prepared to put much more effort into the PCB. This doesn't work well > > unless you're prepared to sit down with the layout person and swap pins on > > the FPGA as you route things up to align with other components on the board. > > For diff pairs be prepared to swap Ps and Ns. You can fix up the inversion > > inside the FPGA.Article: 77285
Hi There, I am an Nios developer , i build toons of project for this excellent soft-core, now i migrate to Nios II, nothing problem except one! i need to convert an .out file to binary using nios2-elf-objcopy ... the line is : nios2-elf-objcopy -O binary xxxx.out xxxxx.bin well the binary come is bigger than the .out ,, normally is the contrary!!!!! i've used every parameter to resize the bin but they don't work.. An Exemples... Nios 1 : .out = 500k .bin = ~200k Nios 2 : .out = 500k . bin = ~ 1200k !!!!!! why? please help me Best Regards Jjleto!Article: 77286
I have done this many times as a contract for other companies that have lost Verilog, VHDL, or AHDL source code. Its quite common to have a .sof in control from manufacturing and missing the source code. For example, if the designer leaves a company and his desktop is lost or changed by IT or if the designer's hard drive has a sudden death and is not under control or backed up. The end result of my disassembling / decompiling the FPGA binary will be much better than a netlist as it will be readable (.v), (.vhdl) . I usually charge anywhere from $3,000 to $7,000 US dollars for the time required in reobtaining the source code depending on the type of FPGA and the amount of LUTS used. I can usually have the source within a time frame of 2 weeks to a month depending on my schedule at the time. If you would like me to give you a quote on recovering your source code you can send me an email at: rcarlson "|AT|" @ skytekinc. "|DOT| " com <=====My correct email is without the spaces and "|AT|" and "|DOT|" quotes above. This is to prevent the spammers from getting my correct email by parsing the messages on this board. Rod Carlson Senior Hardware Engineer Sky Tek Inc. > I realize that this might not be appropriate question for this group, > but considering the level of knowledge I thought I would see if anyone > knows much about recovering lost verilog code from a .sof altera > Quartus FPGA binary? Some of the my companies IP cores source has > disappeared and thought maybe someone here could help me out at > recovering the missing source. Does anyone know of any altera > dissassembler or decompiler for the SOF file? I'm not particularly > concerned if the the output is VHDL, verilog, or even AHDL. Because of > the ethics of reverse engineering I would be willing to present anyone > with the evidence they might need to verify that my company has all > copyrights and ownership of the .sof Im asking to derive the source > code. Any thoughts how I can do this? > Mark S.Article: 77287
Ok, thank you for these answers ! SamArticle: 77288
"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:qZWdnYYDOKj0_0TcRVn-gQ@comcast.com... > Kryten wrote: > >> I wonder how hard it would be to have a small micro (e.g. AVR 2313?) >> reading a FAT-formatted SD card to get a fixed named file (e.g. >> FPGA_CFG.ROM) to load the FPGA? > > Flash file systems are available to do this > if your micro can compile C code. > > Vendor-specific versions are sometimes free. If/when I have time I will look around for code. There are some amateur MP3 player projects on the web, using FAT but they tend to use IDE drives or CF cards. Oh well, they might be a fair starting point...Article: 77289
The problem is that i have two output signals, CE and WE, now i want to "schedule" the rising of WE just after the rising of CE. I tried it by putting the rising statement of CE earlier in the process than the rising of WE, unfortunately, but expectly, without any succes. So how can i "schedule" the rising of the signal after the other. I don`t want to do doubling of the clock, using both clock edges, etc. I hope to do it with just constraints in Xilinx ISE. So can anyone tell me how to fix this problem, any info would be appreciated ! Michel Bieleveld.Article: 77290
Hi, I am interested in doing some performance profiling and benchmarking using FPGA software. Right now, I am looking for a large open source FPGA to play around with. Unfortunately, I don't have a good sense of what constitutes a 'large' FPGA. Right now, I am working with a 35k gate USB controller that was suggested to me (I believe it's available through opencores.org). Does anyone have some other suggestions? Thanks in advance, I would really appreciate some advice and guidance on the matter. David KanterArticle: 77291
"Michel Bieleveld" <aktaeon@gmail.com> schrieb im Newsbeitrag news:47fe273e.0501031255.4e19d7fc@posting.google.com... > The problem is that i have two output signals, CE and WE, now i want > to "schedule" the rising of WE just after the rising of CE. > > I tried it by putting the rising statement of CE earlier in the > process than the rising of WE, unfortunately, but expectly, without > any succes. Sure, we are talking about real world, synthesizable HDL. The delay statements in VHDL are for simulation only. VHDL is concurrent, statements are processed in parallel as fast as possible (given by the target technology). > So how can i "schedule" the rising of the signal after the other. I > don`t want to do doubling of the clock, using both clock edges, etc. I > hope to do it with just constraints in Xilinx ISE. Hope is good, but basic understading of things is better. So how do you think such a thing might be possible.?? Adding a RC-Filter to an IO? There are serval tricks to get a more or less usefull workaround, but a reliable and safe way is to use a clock (and maybe the inverted edge). Nothing wrong with this. You can "adjust" the phase relation also by setting the IO driver to different driving strength and slew rates, but this is IMHO not a clean way (phase will vary with VCC and temperature) Regrads FalkArticle: 77292
"David Kanter" <dkanter@gmail.com> writes:
> Does anyone have some other suggestions?
You could try LEON, a Sparc processor with AMBA and peripherals:
http://www.gaisler.com,
Direkt link to LEON, but a frame:
http://www.gaisler.com/products/leon2/leon_down.html
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Article: 77293Hi > I am interested in doing some performance profiling and benchmarking > using FPGA software. Right now, I am looking for a large open source > FPGA to play around with. Unfortunately, I don't have a good sense of > what constitutes a 'large' FPGA. Right now, I am working with a 35k > gate USB controller that was suggested to me (I believe it's available > through opencores.org). Does anyone have some other suggestions? Well, "open source FPGA" is an abuse of language, a fpga is a hardware piece. The "cores" or "IP blocks" you program/load in them are open sources. If you're just looking for a "big" thing. Look at gaisler leon 3. It's a complete SoC solution with differents cores in it, you can surely configure it to become pretty large. And it's also more "polyvalent" since you have cpu core, memory controller, pci , ... SylvainArticle: 77294
if you want WE to toggle after CE you have two states not one (If you think of your design as a state machine). So doubling the clk is the best solution. That way you'll have WE toggle on one clk edge and CE toggle on the next. It's not the answer you wanted to hear, but i think it is the way that will get you the most consistant results. EricArticle: 77295
Sylvain Munaut wrote: > Hi > > > I am interested in doing some performance profiling and benchmarking > > using FPGA software. Right now, I am looking for a large open source > > FPGA to play around with. Unfortunately, I don't have a good sense of > > what constitutes a 'large' FPGA. Right now, I am working with a 35k > > gate USB controller that was suggested to me (I believe it's available > > through opencores.org). Does anyone have some other suggestions? > > Well, "open source FPGA" is an abuse of language, a fpga is a hardware piece. > The "cores" or "IP blocks" you program/load in them are open sources. I should have known that; thanks for the pointer. Nothing beats looking like a n00b... > If you're just looking for a "big" thing. Look at gaisler leon 3. It's a > complete SoC solution with differents cores in it, you can surely configure > it to become pretty large. And it's also more "polyvalent" since you have > cpu core, memory controller, pci , ... That might be interesting. My rationale for looking for something "big" is that I would like to have reasonably long run times. The USB2 controller I was working with took under a minute to synthesize. One of the problems is that I would like my workload to be as 'real world' as possible, and testing EDA tools with tiny chips isn't very interesting for those who really are using them for work. I don't really know enough FPGA's to explain, but for an ASIC, I am pretty sure that the time to do an extraction for a 1mm^2 chip will be almost entirely uncorrelated to the time for an extraction of similar quality on a 370mm^2 behemoth. The real issue is trying to get a realistic workload and my feelings are that most of what I have seen at opencores.org are 'small'. Thanks for your help everyone I appreciate the comments! David KanterArticle: 77296
> > And for just configuring - have a look at the FTDI chips and bit-bang > > app-notes: > > http://www.ftdichip.com > > > The FT2232 has a dedicated serial engine to generate JTAG/SPI/I2C. However I > have not seen an open project for JTASG interface to use this chip. > If someone cares to do something... The AT91SAM7S64 is nice for the job. * USB Client * ARM7 running at 48 MHz (will not handle 70'C at this temp though) * Built in Flash and SRAM * High speed synch interface for JTAG Master This should be MUCH MUCH fatser than bitbanging. There is of course the small matter of programming... The AT91SAM7A3 is even better, but availability of production part is later. Couped with a dataflash on the SPI bus you coul dbuild a device which looks like a USB Mass Storage Device so you could easily download the bitstream, and at powerup the ARM would configure the FPGA(s) Too lazy to do it myself, but I am sure it would be sellable. Best Regards ulf at a-t-m-e-l.doth com This is a personal view which may or may not be share by my Employer Atmel Nordic ABArticle: 77297
What Eric is suggesting is the cleanest way to do things. Another alternative without going thru re designing logic too much is to use DCM to generate half frequency clk phase shifted by what ever delay you want. Use that clock as a gate to your WE. This will cause bad output times on you WE and could be a concern if you are planning to run at very high speeds and there is no margin to play with (if board delay plus set up times plus clk to q are barely meeting). Else if you are generating WE thru a flop, things are still easier. Use DCM to generate same frequency clk as your core clk, delay phase shift by whatever amount you want and use that to clock your WE. Hope all these help, Regards, Purvesh Eric wrote: > if you want WE to toggle after CE you have two states not one (If you > think of your design as a state machine). So doubling the clk is the > best solution. That way you'll have WE toggle on one clk edge and CE > toggle on the next. > > It's not the answer you wanted to hear, but i think it is the way that > will get you the most consistant results. > > EricArticle: 77298
Last time I checked with EDK6.2i, it did not like embedded spaces in the path name. IIRC, one could either put the files in a path without embedded spaces, or use the subst command. - Newman "R!SC" <opb@xilinx.com> wrote in message news:_XdCd.622615$35.25734702@news4.tin.it... > Hi all, > > i'm first time approch with fpga, i have xilinx ise and edk 6.3i version. > With XPS I have create a new project with project builder on spartan 3 > starter development kit. When i go to compile the project the programm > given back this error: > > > Performing System level DRCs on properties... > INFO:MDT - List of peripherals addressable from processor instance > microblaze_0 > : > - dlmb_cntlr > - ilmb_cntlr > - debug_module > - Generic_GPIO > > Building Directory Structure for microblaze_0 > cd: Too many arguments. > ERROR:MDT - Failed to remove G:\Documents and > Settings\risc\microblaze_0\libsrc\. > LibGen Done. > make: *** [microblaze_0/lib/libxil.a] Error 2 > Done. > > > Have you an idea to resolve this problem? > > thanks > Regards > R!SC >Article: 77299
Is there any reason why using an LM317S adjustable linear regulator with 1% resistors wouldn't be satisfactory for the Spartan 3 power supplies, particularly Vccint and Vccaux? I have a cost-sensitive application for which the LM317S looks to be much less expensive than using fixed-output LDO regulators, e.g., $0.58 for the LM317S vs. $4.45 for an LP3881ES-1.2 for Vccint. Thanks for any advice! Eric
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