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
Benjamin Marpe wrote: > Hi Peter, John and all others ! > > Thanks a lot for your answers! > > In analog technics, I already thought of using a VCTCXO with the desired > amount of frequency variation, driven by a DAC ! > > But if there are other pure digital methods: please keep on posting them ! That is your best approach. The FPGA can verify the frequency, by Freq Ctr, if you wish, and simple PWM/PDM DACs can be made in the FPGA, if the dF precision is not large : it probably is not, 5Hz is 5ppm, so you are unlikely to want that to be 5.000ppm/4.999ppm etc Using an external VCTXO will also give you a truly walking phase, with no steps, which is probably more usefull. -jgArticle: 94876
In article <QFTyf.3436$bF.2359@dukeread07>, Ray Andraka wrote: > > I'm not sure I see what the big push for having bitstream access is. Do you happen to have a means to create a bitstream (from whatever ASCII represented primitives) on for example OpenBSD? Or from a perl script running on an OpenVMS system? Your (the vendor's) tools so lovingly provided are not always the ideal tool for the job, nor is the environment always readily available in order to use them. > I've yet to see a compelling need for it that is not addressed by the > existing tools (there is always XDL if you really want to bit bang). Yes, but how to convert XDL into something that I can shoot into the FPGA? > The only reason that seems to surface is to allow outside parties to > develop their own place and route tools. Frankly, I don't think the > complexity of modern FPGAs is such that this type of undertaking can > improve on or even compete with the free place and route tools already > offered by the FPGA vendors in the timeframe between device introduction > and obsolescence. The gist is not really to compete in a space where a company has invested in millions to create a product, but to play in a space where nobody else is going. > Anyway, for those hadry enough to try, as I said, the > XDL tools do give you enough access to every step of the design flow to > allow you to play with any step you feel compelled to play with. But the tools are in the environment of your choosing. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 94877
Lasse,
I had a similar problem which I solved by writing a Perl script to
create a BMM file containing the locations of the BRAMs after
placement. In my case the tools inferred the BRAMs and I wasn't using
CoreGen, but the idea may work in your case as well. This script uses
XDL to convert the placed NCD file into a text format that can then be
parsed to find the locations of the placed BRAMs. Data2mem then uses
this BMM file to load the BRAMs.
xdl command:
xdl -ncd2xdl ncd_file xdl_file
finished BMM file snippet:
ADDRESS_SPACE lmb_bram_0 RAMB16 [0x00000000:0x00003FFF]
BUS_BLOCK
openfire0/openfire0/MEM/Mram_MEM_inst_ramb_7 [31:28] PLACED =
X3Y13;
Hope this helps,
Stephen
Article: 94878"Antti Lukats" <antti@openchip.org> writes: > <newsmailcomp5@gustad.com> schrieb im Newsbeitrag > news:kjuwtgxefpt.fsf@shardlow.dolphinics.no... > > "Antti Lukats" <antti@openchip.org> writes: > > > >> you can connect Cable III to the JTAG and use impact, or I could > > > > Can you play SVF files with impact? How? > > > yes you can play SVF files with impact, just add them :) I guess you mean XSVF files? I can't find out how to play XSVF files in batch mode, there is a play command but it does not seem to take a filename as an argument. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 94879
Peter Alfke wrote: > > Tobias, this subject has been discussed ad nauseam, in this newsgroup > and elsewhere. Well, talking to actel, they cite "competitor" reasons for not giving away this information. > The reason for the "secrecy" is not so much fear of giving away secrets > to a competitor, but rather fear of becoming inundated with support > issues. We have about 100,000 designers using our parts, a few dozen > of them exploring and abusing subtle aspects could easily bring our > support hotline (and this newsgroup) to its knees. Xilinx (as much as this is "official" in any way) is citing a fear of being not able to meet the support issues. > Also, the non-open nature of the bitstream provides our customers a > certain level of security against reverse-engineering rip-off. Bullshit. I can get the bitstream and parts are readily available. There is little to no need to reverse-engineer your customers' design. It's right there for me to use, should I care to. Also, should I want to reverse-engineer things, it would not be *that* hard. I'm sure that I could get various pieces out of the bitstream that would be usefull to me (along with traces/etc) in doing a 80% job. If you want security, provide it. Have a means to program a OTP flash (or somesuch) piece of hardware on your FPGA with an AES key, and have the bitstream flash device have its bitstream encrypted with the same key. At this point, things would considerably more "challenging" to reverse-engineer. I'm no VLSI designer, but I can't imagine that putting a simple AES engine onto the FPGA, along with some OTP ram for the key, would take any significant room. As a bonus, you may be able to offer the simple AES engine for the FPGA to use once programming is done. > Our primary obligation is to remain an innovative and profitable > company, to the benefit of our customers, our employees, and our > shareholders. Satisfying exotic academic research is fine, as long as > it does not conflict with the primary obligation. Certainly. Does the "idea" I have given above (which is available in many forms on the web, etc) mean that you could use it, implement it, and have yet another innovative & profitable device on your hands? :) Open documentation (not necessarily support) tends to foster collaboration and innovation on many fronts. The "encrypted config bitstream" idea is hardly new or novel, but I'm sure there are many people out there who would welcome the chance to get their creative juices flowing... > Just my personal opinion... Darn. :) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 94880
Scott & Brenda Burris wrote: > > And then there's the little matter of the ML403 kit Xilinx offers with > the Virtex 4 FX and the EDK. As a hobbyist, I'm cringing at the thought > of putting $895 into this. At the same time, I'm going, hmm, what could > I do with the PowerPC chip or the MicroBlaze? Hmm, no it's too much > money.... But I keep thinking about it :-) I know Xilinx doesn't > really target people like me, but I keep hoping for a half-price sale or > a hobby bundle on the ML403 (no support, no commercial use or you give > up your first born, etc). I know what you feel like. We have the XC2S50 here on some demo boards from somewhere. They're ok to play around with. Nowadays I'm salivating over XC3S1500/2000 boards. If I could find something with 3 to 6 of these on board (even the 1000 version), and good chunk of sram, for less than $1k, I'd be a very happy camper... -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 94881
Is your library for the CRC generation available to others. JOhn On Wed, 18 Jan 2006, Antti Lukats wrote: > > "John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag > news:Pine.GSO.4.44.0601172313190.29583-100000@elaine15.Stanford.EDU... > > > > I have configured an XCV1000 as a data and instruction cache. It is > > connected to a external hard core. I would like to be able to update the > > contents of the caches without recompiling the file. I have been using > > Data2mem, but it appears that the CRC bits for the bitstream are not > > recalculated. They are always set to: 0xDEFC > > > > When data2mem modifies a bit file, it apparently turns off CRC checking > > by replacing the calculated CRC value with a constant 0xDEFC (which > > apparently spells DEFault Crc value). 0xDEFC is apparently supposed to > > tell the FPGA not to bother doing a CRC check on load because we were > > apparently TOO LAZY to calculate a correct value to check against. > > > > I found one (non-xilinx) web site that indicated that Virtex-II etc. will > > work just fine without a valid CRC value, but not so for Virtex. > > > > ngdbuild, or one of those tools near it, explicitly states that "-g > > CRC:DISABLE" is a valid command line option for Virtex-II but not Virtex, > > and indeed project navigator complains when I attempt "-g CRC:DISABLE" for > > our part. > > > > It seems clear at the moment that data2mem is not calculating CRC values > > but is calculating a bypass value instead; and it's less clear, but all > > signs seem to indicate, that that would work for Virtex-II and later parts > > but won't work for Virtex. > > > > I think there must be a way to get the CRC in the bitfile, hopefully using > > data2mem, but I haven't found it yet. > > > > Has anyone run into this problem and solved it? Here is a diff of the two > > bit files. > > hi John, > > we are using internally libraries that read bitstreams and recalculate the > CRC, > it is currently being used to fix the oscillator optons for Spartan3e, but > with > no big mods it should be able to process virtex bitstreams as well. > > so as one option is to have a simple command line tool that post-process > the bitstream and injects the proper CRC. > > and you are right DEFC is DEFault Crc that is needed to be written > in place of real CRC and also in place of autoCRC, also the CRC > bypass bit in COR must be set. > > and as noted not all familes support the CRC bypass > > Antti > > > > > > > > > > > > > John D. Davis PhD Candidate Computer Systems Lab Office # 1.650.723.6891 Stanford University Fax # 1.650.725.6949Article: 94882
Jim, I suggest those who are serious about these sorts of legal agreements hand the agreement to their company's attorney. I gave only one example, of a 'project license'. There is also a 'site license'. So far, 97% of them like the agreement enough not to mess with it. If you don't like our terms, then we are more than happy to agree on terms which will make both you and Xilinx happy. AustinArticle: 94883
Tobias, -snip- > If you want security, provide it. Have a means to program a OTP flash > (or somesuch) piece of hardware on your FPGA with an AES key, and have > the bitstream flash device have its bitstream encrypted with the same > key. At this point, things would considerably more "challenging" to > reverse-engineer. I'm no VLSI designer, but I can't imagine that putting > a simple AES engine onto the FPGA, along with some OTP ram for the key, > would take any significant room. As a bonus, you may be able to offer > the simple AES engine for the FPGA to use once programming is done. Not that we will not do what you suggest (someday), but reverse engineering OTP memory is very cheap, and is considered quite insecure. That is the reason why RAM backed up by a battery is the only solution that is acceptable to the US federal government (FIPS-41), and to TV set cable box vendors... The one time programmable key might be sufficient as a deterrent, and will certainly slow down the process of ripping off the design. I agree. But please do not put it forth as being "secure." AustinArticle: 94884
St=E9phane, I do similar designs to this (framegrabber cards) and haven't found a ready-made SDRAM FIFO, although I haven't looked in a long time since rolling my own many designs ago. I think that getting good performance from SDRAM in this situation involves tuning the burst accesses to allow continuous use of the data bus when not changing direction between read and write. Peter was on the right track with the read / write ping-pong machine, but for SDRAM you need to read multiple words / write multiple words to get any sort of performance. A design I re-use frequently has a constant 21-cycle loop in which 16 of the cycles are used for either read or write (not both) during one loop. Un-needed loops are replaced by a 21-cycle NOP and auto refresh. Start-up code counts refresh loops until 8 refreshes occur and then sets the mode register. For simplicity, the address pins are reset to the state required for the mode register set (MRS) and not clock enabled until the MRS has completed. This reduces the gate depth of the address mux. I have a simple "arbiter" that decides what to do with the next 21 clock cycles (read, write, or refresh). To reduce power on some designs I only refresh if a refresh timer has expired, then unused 21-clock loops are just completely NOP'd. Memories are set for burst length of 4 and one burst of 4 words is sent to each bank (thus overlapping data and control cycles). Think of the bank address as the least significant address bits. For better throughput you can increase the loop length and each additional 16 cycles would add 16 more memory accesses (e.g. 32 accesses in a 37-cycle loop). The basic element going in or out of this "FIFO" is then a burst of 16 words (think of this as your FIFO width if you will. Generally I use a COREgen FIFO to buffer up data at both ends of the SDRAM to deal with asynchronous data rates and differing byte widths on input and output. The whole design is remarkably small, but as I said I haven't seen such a design made generally available. Good luck, Gabor sjulhes wrote: > Hello, > > The goal is not to create delay but to handle the fact the 32 bits / 33 M= hz > bus is not always available. > > For the SDRAM controller I already have my solution in mind. > > I was only wondering if this function ( huge FIFO for FPGA using an exter= nal > SDRAM ) ,which i'm shure a lot of people would need, would already exist = and > be available. > > St=E9phane. > > "Peter Alfke" <peter@xilinx.com> a =E9crit dans le message de news: > 1137514850.769502.197970@f14g2000cwb.googlegroups.com... > > Give more details: > > depth, width, clock rate for write and for read. Asynchronous clocks? > > Peter Alfke, Xilinx > >Article: 94885
> * Impact does not work out of the box with kernel > version 2.6.15.1. I had to download linuxdrivers2.6.tar.gz > and compile it. Furthermore, I had to edit the configure > script in windrvr and make sure that UDEV was not used. > (The udev interface seems to have changed in later 2.6.x > series. The relevant symbols are also GPL-only now, so I don't > think a binary only module can be distributed using UDEV in later > 2.6.x kernels.) I wrestled similarly with windrvr. It apparently uses some class_simple functions removed Jun. 20 2005. I subscribe to the LKML and was easily able to reverse patch it. Project manager and some other window were converted to QT I think. All other windows use the hideous WindU lib, so you can start the ise executable without fooling with DISPLAY but you still need it set to ":0" for all those secondary programs. Other than the subpar hotkey junk, the interface is much more natural. Everything much more usable now. (Gentoo, 2.6.14-gentoo-r4 w/ class_simple unpatch, WebPack 8.1, Spartan-3 starter kit w/ parallel cable III).Article: 94886
See http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=22648 for tar.gz link and instructions.Article: 94887
On 18 Jan 2006 05:19:22 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: >In article <9p7ns1pch437c81ln9dunkk34bo5p2k3ab@4ax.com>, >Brian Drummond <brian@shapes.demon.co.uk> wrote: >>On 15 Jan 2006 21:39:16 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: >>Last really open system was the XC6200. But it failed commercially, at >>least in part, because it was a finer grained architecture. >> >>FPGA capacities should now be big enough to support a "virtual FPGA" >>layer on top of a real FPGA, using only the "public" parts of the >>bitstream >>I think it would be big enough to exercise open source development tools >>until something better came along... >> > >Interesting idea. Are you saying that a XC6200 model would be developed in >HDL and then run through synt, p&r, etc. and that could then be used for >downloading the bitstream to? Something like that; though I doubt the XC6200 would be the best starting point. >...but like you say, you would be taking a big performance/area hit. > >If you were going to do that, then why not just create some sort of >higher level Virtual FGPA device (kind of like what a Virtual Machine is to the >software world) that would have lots of nice high-level features (high-level >macros available, etc.) and also be tunable for the underlying architecture >(depending on whether the target was Xilinx, Altera, or Lattice. It looks possible, especially if the basic elements were a common-denominator subset of individual targets like Xilinx; e.g. 4-input LUTs followed by registers, with some sort of carry chain. >Also, just like the Java VM doesn't care what >underlying architecture it's running on, this sort of thing could potentially >make it easier to port designs between FPGA families... But no easier than behavioural VHDL code, in my opinion. >I wonder if it could be >done such that there is a minimal impact on performance and area? ummm, in a sense; if you are willing to use the "native" routing on each target, and allow each company's "native" tools to perform the routing, placement, bitstream generation (because they know the details of that target and its bitstream). And even then, you will lose some performance on at least some targets. But that is a completely different issue than trying to keep every level of the design "open"... IMO the closest you will get to allowing open tools to participate WITHOUT taking a big performance hit is the XDL approach. It's a text version of the NCD format - parseable and even human readable - with converters to/from NCD format. So you could potentially take an EDIF netlist and create open source tools to "map" it to an unplaced XDL, or use the Xilinx mapper and convert its output to XDL. Then create open source tools to floorplan, place and route in XDL format. Those portions of the tool flow are where the challenges are; and if you create something worthwhile, it would be useful to many Xilinx users. You would realistically then have to use Xilinx tools to convert XDL to NCD and translate the completed design into a bitstream format. This is pretty much a straight translation and not very interesting in my book; though it would be a wart on an otherwise complete open source toolchain. - BrianArticle: 94888
On 18 Jan 2006 08:52:53 -0800, langwadt@ieee.org wrote: >Hi, > >Does anyone have a hint on how to get data2bram and coregen memory to >work together? >data2bram does give me a warning the the memory is not LOC'ed, is there >a simple way to >get that info when the memory is generated with coregen? You could get that information via the floorplanner (load the placed design, then "write UCF" command) and extract the LOC lines relevant to the BRAMs. To ensure consistency in future placements, you can add those LOC lines to your UCF file. Or you could place the BRAMs yourself, again with the floorplanner first time round, and subsequently via UCFs. - BrianArticle: 94889
OK, I just have to vent a bit. I am laying out a board with an XC9536. The schematic capture program I am using is a major program, not some fly by night outfit. They claim their component library is done by an ISO 9000 organization. So my perfectionist tendencies didn't like the fact that they used a different font for the pin names on the XC9536 schematic symbol than they usually do in the libraries. I went into the "Library Executive" to change the font and when I went to save the part the program told me that the pin numbers in the component pin list didn't match what was entered into the schematic capture symbol. So I checked the XC9536 data sheet and found out that their pin numbers for the schematic symbol were ALL WRONG. I had to spend about half an hour relabeling all the pins, and then moving things around to make it look nice again. So if I hadn't decided to change that font, I could have done a board layout with all the pins connected wrong. I'm starting to think it would be better if board layout programs just shipped with no pre-made components. I just end up fixing things on nearly every single part I use anyway. Sometimes I think it would be better if I just did it all myself.Article: 94890
Hi all, I have got a doubt in PCI arbiter operation . Assume that a particular device issues a REQ(REQ0) and GRANT(GRANT 0) is issued to that particular deivce , that device pulls the FRAME signal low indicating it is using th PCI bus.Now during the entire duration for which the FRAME signal is low GRANT(GRANT 0) should be held low for that particular device. My doubt is if in the FRAME low held duration if any other device issues a REQ (i.e pulls it low and again pulls it high before the FRAME has gone high.IS this a valid request OR does the REQ line need to be held until the GRANT is issued to that particular device. Thanks in advance, PraveenArticle: 94891
This kind of design has too many variables and trade-offs that different users will never agree upon. I started thinking SRAM, which is the right approach up to a certain size. Cost is the question. Then there is speed and acceptable through-delay or latency or block length. I still believe in using a dual-ported BlockRAM a the staging area, because it offers so much timing flexibility. Peter AlfkeArticle: 94892
Tobias, we love universities and their students and faculty for their uninhibited free thinking, unburdened by mundane practicality. But beware that some of your sentences sound not just enthusiastic and uninhibited, but also ill informed. Life would be easy if the world were a simple as you see it. Of course we have evaluated non-volatile storage on an FPGA, and we offer a decryption engine in every Virtex-4 device that we ship. With battery-backed-up SRAM key storage, because we know that Flash storage offers no security worth talking about. And several smart people at Xilinx (and surely also in Altera) are still thinking very hard about a technically and economically viable solution. We gladly take advice. But it has to be more substantial than what you seem to offer. Peter AlfkeArticle: 94893
Wow! Late night. Funny... I meant sued. ;) Geeze!
Henry S. Courbis
www.GSE-Reactive.com
"Henry" <apl2research@comcast.net> wrote in message
news:n56dnS9tOtXoQlDeRVn-ug@comcast.com...
> Hey guys. I believe Grant wants to make an EXACT clone of the Mac. I
> agree about the "Firmware" issue. As software is has an unlimited, or at
> least very long life span. Of course being sewed for an exact clone is
> possible, I don't think Apple would care unless you somehow manage to
> become some major market player by doing so, which is even more unlikely
> then being sued in the first place.
>
> I'm currently cloning an old SCSI controller from Apple, ROM included, if
> they do try and send a "nasty-gram" I will promptly remove the ROM from
> the card and anyone who purchases the card could just download the ROM
> from a number of other sites and burn their own. The fact that Apple
> isn't going after these "other" sites is probably a good indication that
> they just don't give a crap one way or another about it. Need I mention
> the expense and bad publicity if they were to do so, and for what? They
> couldn't stop me selling the hardware, just their Firmware.
>
> I say screw em' Grant, and do it anyway. I can only hope they try and sew
> me. I'd love to go on CNN and be interviewed. Free advertising!
>
>
> Henry S. Courbis
> www.GSE-Reactive.com
>
> "Eric Smith" <eric@brouhaha.com> wrote in message
> news:qhacdzsk6g.fsf@ruckus.brouhaha.com...
>> Austin Lesea wrote:
>>> Xerox PARC tried to buy a DEC 10, but DEC wouldn't sell them one.
>>
>> No. Xerox wouldn't let them, since they'd just purchased Scientific
>> Data Systems (SDS), which they renamed to XDS. The corporate types
>> thought (perhaps correctly) that it would negatively impact XDS sales
>> if customers got wind that XDS machines weren't good enough for Xerox'
>> own internal use.
>>
>> Of course, the fact that PARC built their own PDP-10 rather than using
>> XDS machines would send the same message to customers.
>>
>>> So, Xerox got the schematics, put everyone to work, and built one.
>>
>> Xerox may or may not have had the DEC schematics, but they designed their
>> own PDP-10 clone ("MAXC") from the ground up. There was no real
>> similarity
>> to the DEC hardware; MAXC was simply designed to execute the same
>> instruction set.
>>
>>> Just one.
>>
>> Two, actually. And the second was a redesign, not a copy of the first.
>>
>>> Used it for research. Even made their own operating system for
>>> it.
>>
>> They wrote their own operating systems for various small computers they
>> developed, but on MAXC they used TENEX, which came from BBN. A few
>> years later DEC used TENEX as the basis for TOPS-20, which ran on the
>> PDP-10 processor of the DECSYSTEM-20.
>>
>>> Nothing DEC could do: Xerox PARC did not derive any profit from it,
>>> did not use it to do any product (and they had the losses to prove
>>> it!).
>>
>> That wasn't the issue. There weren't any patents on the PDP-10
>> instruction
>> set. If there were, DEC might have had grounds to sue, even though PARC
>> didn't ship it as a product.
>>
>> Profit is not the same as economic benefit. Even if Xerox posted a loss
>> every year that they were using MAXC, it's quite possible that they would
>> have had a larger loss without it. MAXC contributed to the development
>> of many successful Xerox products.
>>
>> If company A sells some patented product P, and company B decides that
>> buying a P would save them lots of money, but builds their own P to
>> save even more, you can bet that company A will sue if they get wind
>> of it.
>>
>> Unless, of course, company B develops P2, which does not use the patent
>> claims held by A. In which case they still might get sued, but will
>> have a better defense.
>>
>> I've personally been involved in a case where a company build a clone
>> of something, carefully avoiding the patents, but was threatened with
>> litigation and negotiated a license rather than spend a bunch of money
>> to try to defend it.
>>
>>> I wonder if today Apple would even care if you went into business
>>> offering (old) Mac Clones?
>>
>> They're not going to care unless you include a copy of the Mac ROM,
>> which is the main component of the "secret sauce" of the Macintosh.
>>
>>> As long as you are not using their IP, their patents (and not
>>> impacting their present business), they really have no reason to care.
>>
>> But of what use is a Mac clone without a ROM? It's arguably of even
>> less use than a newborn baby.
>
>
Article: 94894
hi joey,
thank you for your response.
i tried using mfs_init_genimage as you suggested. and am able to change
to the directory and also able to read the name of the directory using
mfs_get_current_dir_name funtion. but when i try to open the file i am
not able to. i used the mfs_ls() funtion to get the directory contents
but am getting a lot of garbage like
...
mnt 0
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
.. 00000000
00
. 00000000
0000
mnt 00000000
.. 00000000
00000000
. 00000
00000000
.....
but the image of the filesystem generated using mfsgen on my host
system is proper which i checked using the command below in the XMD:
$ mfsgen -tfv image.mfs
mfsgen
Xilinx EDK 7.1.2 EDK_H.12.5.1
Copyright (c) 2004 Xilinx, Inc. All rights reserved.
Directory mnt 4
1_1_0.mnt 3072
1_1_0d.mnt 3072
cd..
mfsgen done!
any suggestions/ideas where i might be going wrong.
Thank you,
Rajashekar
Joseph wrote:
> I used xilmfs once...
>
> Did you use the mfsgen utility to make your file system? If so you
> probably need to use mfs_init_genimage instead of mfs_init_fs.
> Essentially they vary by adjusting some pointer a byte or two (or four
> or whatever). I used mfsgen and then downloaded like you mentioned and
> then did this in my main:
>
> /* Set up the file system and cd to correct dir */
> mfs_init_genimage(53200, (char *) MFS_BASE_ADDRESS, MFS_INIT_TYPE);
> xilmfs_result = mfs_change_dir("my_fs");
> xilmfs_result = mfs_get_current_dir_name(dirname);
> if(xilmfs_result == 0) {
> printf("Couldn't get current_dir_name.\r\n");
> printf("Exiting...\n");
> exit(1);
> }
>
> I don't recall if the 53200 is the value I got directly from mfsgen or
> not... maybe have to adjust it a little? Like it could have been 53204
> or something (again with the pointer adjustment). Sorry if I am a
> little vague, it was a while ago that I set this up. The moral of this
> story is try mfs_init_genimage.
>
> Joey
Article: 94895Ben, Write a clock divider having the divider as input signal (and not as generic parameter). ==> in this divider, u count clk cycles , when count reaches divider, u toggle divided clock once again the divider is an input signal ( be careful to register it on clk falling edge to avoid pbs...) F' = F / (2*(1+k)) where k is the divider if you have say F=48 MHZ , k = 23 gives you a 1.00 MHz clock , k = 22 a 1.0435 Mhz , k=24 a 0.96 Mhz clk etc... ....k=24e6 --> F'= 1Hz.... "Ben Marpe" <Ben.Marpe@gmx.de> wrote in message news:1137597178.426492.225110@z14g2000cwz.googlegroups.com... > Dear experts in this newsgroup, > > in my diploma thesis i'm using a FPGA for baseband signal generation. > I'm interested in generating and varying a clock of 1Mhz which is > DOPPLER shifted +/- 5Hz due to movements between receiver and > transmitter. > > The +/- 5Hz Doppler must be applied in a very "smooth" way, the step > resolution should be as fine as possible. > > Any ideas how to do this on a (Xilinx) FPGA ? > The sine output of Xilinx LogiCore DDS isn't necessary and the step > resolution might be even a little bit finer for my application. > > Thanks a lot for every single hint you can give to me ! > > Greetings, BEN >Article: 94896
Jerome, Ben wants to change the clock in smaller increments than 1 ppm (I suppose something like 0.1 ppm, which gives him 50 steps up from nominal 1 MHz, and 50 steps down from 1 MHz.) I see no way to achieve that with digital divider stages from a <1 GHz oscillator. As already suggested, a pullable xtal oscillator (VXCO) is his best bet. Peter AlfkeArticle: 94897
In article <p1rts1ldm6fh1safm8an5hincq0tv5vfcm@4ax.com>, Brian Drummond <brian@shapes.demon.co.uk> wrote: >On 18 Jan 2006 05:19:22 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: > >>In article <9p7ns1pch437c81ln9dunkk34bo5p2k3ab@4ax.com>, >>Brian Drummond <brian@shapes.demon.co.uk> wrote: >>>On 15 Jan 2006 21:39:16 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: > >>>Last really open system was the XC6200. But it failed commercially, at >>>least in part, because it was a finer grained architecture. >>> >>>FPGA capacities should now be big enough to support a "virtual FPGA" >>>layer on top of a real FPGA, using only the "public" parts of the >>>bitstream >>>I think it would be big enough to exercise open source development tools >>>until something better came along... >>> >> >>Interesting idea. Are you saying that a XC6200 model would be developed in >>HDL and then run through synt, p&r, etc. and that could then be used for >>downloading the bitstream to? > >Something like that; though I doubt the XC6200 would be the best >starting point. > >>...but like you say, you would be taking a big performance/area hit. >> >>If you were going to do that, then why not just create some sort of >>higher level Virtual FGPA device (kind of like what a Virtual Machine is to the >>software world) that would have lots of nice high-level features (high-level >>macros available, etc.) and also be tunable for the underlying architecture >>(depending on whether the target was Xilinx, Altera, or Lattice. > >It looks possible, especially if the basic elements were a >common-denominator subset of individual targets like Xilinx; e.g. >4-input LUTs followed by registers, with some sort of carry chain. > >>Also, just like the Java VM doesn't care what >>underlying architecture it's running on, this sort of thing could potentially >>make it easier to port designs between FPGA families... > >But no easier than behavioural VHDL code, in my opinion. True. The only gains might come when describing memories and other larger blocks which tend to be different from family to family... but there are other easier ways of 'genericisizing' those things too. > >>I wonder if it could be >>done such that there is a minimal impact on performance and area? > >ummm, in a sense; if you are willing to use the "native" routing on each >target, and allow each company's "native" tools to perform the routing, >placement, bitstream generation (because they know the details of that >target and its bitstream). And even then, you will lose some performance >on at least some targets. > >But that is a completely different issue than trying to keep every level >of the design "open"... > > >IMO the closest you will get to allowing open tools to participate >WITHOUT taking a big performance hit is the XDL approach. It's a text >version of the NCD format - parseable and even human readable - with >converters to/from NCD format. So you could potentially take an EDIF >netlist and create open source tools to "map" it to an unplaced XDL, or >use the Xilinx mapper and convert its output to XDL. Then create open >source tools to floorplan, place and route in XDL format. Those portions >of the tool flow are where the challenges are; and if you create >something worthwhile, it would be useful to many Xilinx users. > Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably not likely, but one can wish) >You would realistically then have to use Xilinx tools to convert XDL to >NCD and translate the completed design into a bitstream format. This is >pretty much a straight translation and not very interesting in my book; >though it would be a wart on an otherwise complete open source >toolchain. Well, you have to start somewhere. PhilArticle: 94898
When you say "when i try to open the file i am not able to", what happens? How are you opening the files? What flags are you using to generate image.mfs? It may be necessary to use the -s flag (see Answer Record:19867 on the xilinx site). That flag switches the endianess. Are you using a PPC or microblaze? My only experience is with the PPC. One more thing to try is sticking a small (few chars) txt file in your file system and see if you can peek at it with XMD to see the correct values. Let me know how it goes... I know it took me a while to get my file system working like I wanted it to. JoeyArticle: 94899
In article <1137574950.42552.0@demeter.uk.clara.net>, John Adair <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >Phil > >What you need as a driver depends on your software. I'm not a softy so I am >not best person to talk about this. If you simply want to use a PC slot to >power the card or do what Antti has done with his design that turns a RS1 >into a parallel port look-alike you can get away without supplying a driver. I don't need to be able to program the part on the board through PCI (I could program it through the parallel cable), but after the part is programmed I want to be able to transfer data between the CPU and the FPGA over the PCI bus. If I understand correctly, I only need the driver if I want to be able to program the FPGA through the PCI - is that a correct assumption? > >We are getting a drivers, XP and Linux, for our own PCI core but probably >4-8 weeks away from releasing the first of these. We have a number of >customers using Linux on various boards so if you ask in the Linux community >newsgroups someone may offer a driver. Sounds good (if I could program the FPGA through the PCI bus, that would be great, but it's not absolutely needed I think). Is your PCI core freely available with the board? Phil
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