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
This question comes up more often than most of us care to admit. The bitstream is largely considered proprietary, and there is plenty of potential for doing damage if not correct. Before attempting this, one should be thoroughly familiar with the fpga details and then some. Rather than trying to re-invent the tools, you'd be better off working with the tools. The xilinx tools do give you several entry points into the tools from which you can bypass the previous stuff without getting into the nuts and bolts of the bitstream. First stop would be using any one of a number of third party entry tools. The synthesizers as well as the schematic translators all have one of two formats of the output to go into the FPGA point tools. Those are edif and xnf. The edif format is pretty much an industry standard, and while it is not real user friendly, it could be used to enter a design directly. The contents of the edif netlist are xilinx primitives along with any attrubutes passed from the source, plus block boxes for other linked in edif netlists. The xnf format is an older xilinx specific format which frankly is a little easier to decipher or parse. I don't know how long, going into the future it will continue to be supported, as the clear preference is for edif. The advantage of going in to the front end of the xilinx tools is that you can link in third party macros, and you get the full benefit of the mapper, floorplanner, place and route and bitstream generator. If you don't want to use those for whatever reason (evolution is one of the more valid reasons I've heard), then you could use jbits to generate the bitstream from your own stuff. If you are so inclined, you could also enter the design through the FPGA editor, bypassing everything but the bitstream generation, at the espense of more tedious work. longwayhome@my-deja.com wrote: > > Hi > I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on > it. With the board came a utility which can send compiled bitstreams to > the chip. I'd like to manually generate the bitstreams though, rather > than compile them from a vhdl spec though, as my intention is to > program it using evolutionary algorithms and I think this would be > easier and faster than actually generating vhdl and compiling that then > sending that to the chip. > > Does anyone know where I can find a spec which would show exactly how > the bitstreams are interpreted by xcv100 ? I've already had an > unsuccessfull look at the Xilinx site (but i've had problems finding > what i want there before...) > > I'm a complete beginner at this, all advice greatfully accepted. > > Thanks > > David > > Sent via Deja.com > http://www.deja.com/ -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 28151
SERIOUSLY THIS IS NOT A SCAM! LOTS OF CASH, FAST AND COMPLETELY LEGAL, THIS REALLY WORKS!! THIS REALLY CAN MAKE YOU EASY MONEY!! IT WORKS!!! BUT YOU HAVE TO FOLLOW IT TO A LETTER FOR IT TO WORK!!!! A little while back, I was browsing through newsgroups, just like you are now, and came across an article similar to this that said you could make thousands of dollars within weeks with only an initial investment of $6.00! So I thought,"Yeah, right, this must be a scam", but like most of us, I was curious, so I kept reading. Anyway, it said that you send $1.00 to each of the 6 names and address stated in the article. You then place your own name and address in the bottom of the list at #6, and post the article in at least 200 newsgroups. (There are thousands) No catch, that was it. So after thinking it over, and talking to a few people first, I thought about trying it. I figured what have I got to lose except 6 stamps and $6.00, right? Like most of us I was a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 or www.usps.gov) and they confirmed that it is indeed legal! Then I invested the measly $6.00. Well GUESS WHAT!! ... Within 7 days, I started getting money in the mail! I was shocked! I figured it would end soon, but the money just kept coming in. In my first week, I made about $25.00. By the end of the second week I had made a total of over $1,000.00! In the third week I had over $10,000.00 and it's still growing. This is now my fourth week and I have made a total of just over $42,000.00 and it's still coming in rapidly. It's certainly worth $6.00, and 6 stamps. Let me tell you how this works and most importantly, why it works.... also, make sure you print a copy of this article NOW, so you can get the information off of it as you need it .. STEP 1: Get 6 separate pieces of paper and write the following on each piece of paper "PLEASE PUT ME ON YOUR MAILING LIST." Now get 6 US $1.00 bills and place ONE inside EACH of the 6 pieces of paper so the bill will not be seen through the envelope to prevent thievery. Next, place one paper in each of the 6 envelopes and seal them. You should now have 6 sealed envelopes, each with a piece of paper stating the above phrase, your name and address, and a $1.00 bill. What you are doing is creating a service by doing this. THIS IS ABSOLUTELY LEGAL! Mail the 6 envelopes to the following addresses: #1)Ike, 2900 Canby Ct., Northfield, MN 55057 #2)D. Gerow, P.O. Box 579574, Modesto, CA 95357-9574 #3)V. Williams, 222 East Avenue G Hutchinson 67501 #4)J.Morton, 475 N.W. Walnut Blvd., Corvallis, OR 97330 #5)S. Dorman, P.O. Box 4222, Ft. Polk, LA 71459 #6)D. Abu Harb,2238 New Hope Church Rd. Raleigh,NC 27604 STEP 2: Now take the #1 name off the list that you see above, move the other names up (6 becomes 5, 5 becomes 4, etc...) and add YOUR Name as number 6 on the list .. STEP 3: Change anything you need to, but try to keep this article as close to original as possible. Now, post your amended article to at least 200 newsgroups (I think there are close to 24,000 groups). All you need is 200, but remember, the more you post, the more money you make!!! .. DIRECTIONS ---HOW TO POST TO NEWSGROUPS---- Step 1) You do not need to re-type this entire letter to do your own posting. Simply put your cursor at the beginning of this letter and drag your cursor to the bottom of this document, and select 'copy' from the edit menu. This will copy the entire letter into the computers memory. Step 2) Open a blank "notepad" file under accessories in windows and place your cursor at the top of the blank page. From the 'edit' menu select 'paste'. This will paste a copy of the letter into notepad so that you can add your name to the list. Step 3) Save your new notepad file as a .txt file. If you want to do your postings in different settings, you'll always have this file to go back to.Article: 28152
In article <ee6f135.10@WebX.sUN8CHnE>, "Pascal C." <> writes: > The pins on which I am trying to reduce the drive are LVTTL. I've constrained > them to a Clock to out of 6 ns, to allow some setup time (the clock is 131M, so > clock period is about 7.8ns). Under 12 mA, it tells me it can't possibly meet > a clock to out of 6 ns. And fails. > > I finally got an answer from Xilinx TechSup. They told me I had two choices: > a) ease off the constraints so that PAR will complete, or b) change all pins > manually. The key thing you have to understand is the data sheet. As you set the drive to lower current, the clock-out takes longer. Be thankful that you are getting error messages rather than circuits that don't work when the chip gets warm and/or VCC is a bit low. -- These are my opinions, not necessarily my employers. I hate spam.Article: 28153
> (3) Do builds from the command line. Learning how to use ``make'' will > vastly repay the effort. How many other people would be happier if Xilinx "supported" make style development? I think the key part that I haven't found is a file flow diagram. What files are "source" and need to be preserved by RCS/CVS/whatever? What files are machine generated (and easy to recreate) and which programs make them? Which files do those programs read? Yes, I'm fishing for the data needed to build a makefile. An app-note would be a wonderful idea. -- These are my opinions, not necessarily my employers. I hate spam.Article: 28154
"Hal Murray" <murray@pa.dec.com> wrote in message news:921hee$sv0@src-news.pa.dec.com... > How many other people would be happier if Xilinx "supported" make style > development? Although they don't really "support" it, I don't think they at all opposed to it either... > I think the key part that I haven't found is a file flow diagram. > What files are "source" and need to be preserved by RCS/CVS/whatever? > What files are machine generated (and easy to recreate) and > which programs make them? Which files do those programs read? I think the easiest way to determine these things is to look in the log file generated by the "pushbutton" flow and then read up on the command line parameters for all the programs invoked. It would be nice if someone summarized this all into a chapter somewhere. ---Joel KolstadArticle: 28155
Hal Murray wrote: <snip> > > Similarly, I'd like a tool that would raise a red flag if a signal > from a different clock goes to more than one FF. > <end-snip> This isn't all that hard to do by post-processing e.g. the synthesis or post MAP simulation netlists *except* that the simple minded way of doing it generates screeds & screeds of junk warnings. This comes about from the typical situation where for example you have some sort of bus. Synchronising the ``request'' bit is all you need in general since when that's cleanly across domains you can assume that all the rest - address/data/direction etc. - has been stable for at least 1 whole period of the target domain clock. Therefore what's needed is some attribute you can set at the HDL/schematic level that says ``this is a synchroniser FF'' and propagates all the way through the build chain. Then you can do both the reg-flagging stuff and <dream -on> put some metastability analysis into the STA [Trace] tools <dream -off>. Peter: Here's a suggestion - How about a new timing constraint INST "foo" SYNCHRONISER;Article: 28156
Hal Murray wrote: > > I just had a look at the online docs, and it's pretty much all covered > > in the first few pages of: > > > > Synthesis and Simulation Design Guide > > Chapter 4: Designing FPGAs with HDL > > Using Dedicated Global Set/Reset Resource > > Thanks. Interesting that it doesn't say anything like that > in the data sheet. > > -- > These are my opinions, not necessarily my employers. I hate spam. But with all this there is still no way [according to Evan] to turn off the implicit GSR that happens during config.Article: 28157
Hal Murray wrote:
> > (3) Do builds from the command line. Learning how to use ``make'' will
> > vastly repay the effort.
>
> How many other people would be happier if Xilinx "supported" make style
> development?
>
> I think the key part that I haven't found is a file flow diagram.
> What files are "source" and need to be preserved by RCS/CVS/whatever?
> What files are machine generated (and easy to recreate) and
> which programs make them? Which files do those programs read?
>
>
The answer to this is basically every text file that's not generated by one
of the tools in the flow. So if the flow is something like
Source files <-- Verilog, VDHL
Synthesis <-- side files e.g. constraints, IO buffer defs
etc.
NGDBUILD <-- UCF + e.g. CoreGen netlists
MAP <-- Extra PCF constaints
PAR/TRCE [I always run these as a pair]
BitGen/PROMGen
at each of these stages I use the -f flag to pass arguments to the tools so
that the arg files can be archived as well. Then roughly speaking all the
stuff coming in from the right is archived.
o I've got a lot of Perl scripts that hack about in the flow that get
CVS'ed.
o When I do a release I'll generally archive all the tool log/report files.
Not really necessary but useful.
o Don't forget the most important of all - the makefile itself.
All this can add a couple of hours overhead when checking in all this stuff
to the archive but I've lost count of the number of times I've spotted
something wrong during the actual checkin process. Classically its things
like changing the polarity on some register bit - which will make the s/w
break.
After all this what you've got is a *reproducible* version of the big green
GUI button:
gmake <design>.exo
then go away & have a decent lunch, go running, play a game of squash, or
even get on with the next design.
Article: 28158Hal Murray wrote: > > (3) Do builds from the command line. Learning how to use ``make'' will > > vastly repay the effort. > > How many other people would be happier if Xilinx "supported" make style > development? > > I think the key part that I haven't found is a file flow diagram. > What files are "source" and need to be preserved by RCS/CVS/whatever? > What files are machine generated (and easy to recreate) and > which programs make them? Which files do those programs read? > > Yes, I'm fishing for the data needed to build a makefile. > > An app-note would be a wonderful idea. We published an appnote about using makefiles with Foundation and FPGA-Express at http://www.xess.com/manuals/fndmake.pdf. It doesn't address the file dependency issue, but it shows which programs are called and in what sequence. > > > -- > These are my opinions, not necessarily my employers. I hate spam. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 28159
longwayhome@my-deja.com wrote: > > If you want to put on any Xilinx ( or Altera or > Atmel) > > FPGAs, don't do it ! > I didn't actually want to treat the bitstreams themselves as a piece > of 'dna' to mutate/breed etc although now that you've mentioned that > idea an XC6200 board would be a nice thing to have (if xilinx have any > such boards lying around destined for wastage... :-) I don't think any kind of evolving is possible in the line of digital circuits in standard logic.Comparing FPGA's with carbon-based-logic is like comparing Apples and Turnips. The closest I can see something is with cellular logic like "life". Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchukArticle: 28160
Solved... The answer (provided by Hal Murray, thanks Hal!) was to do the following: // // The MF input flops should be in the IOB, since the MF clock is much faster than the LF // and in order to do this, we have to use xc_props to pass the attribute to the Xilinx map program // or it'll map the LF flops into the IOB... // input [15:0] I_c_adc_din ; reg [15:0] c_adc_lf_din /* synthesis syn_preserve = 1 xc_props = "IOB=FALSE" */ ; reg [15:0] c_adc_mf_din /* synthesis syn_preserve = 1 xc_props = "IOB=TRUE" */ ; It appears the "syn_useioff" can only be on input/output statements, and are ignored on reg statements... Austin Franklin <austin@darkroo98m.com> wrote in article <01c06bcb$b13d6da0$2404f7a5@drt1>... > I have an input that has two flops for destinations. I want one of them to > be in the IOB, and the other flop to use a CLB flop, and the tools do > that....but it's the wrong one that ends up in the IOB. > > I have an <all> syn_useioff in the .sdc file, and I also use the map option > -pr b...that's how the FFs get in the IOBs in the first place...and I've > tried both specifying that specific register as syn_useioff in the .sdc > file, as well as the <all>, and I've tried giving the Verilog the /* > synthesis syn_useioff = 1 */ on that particular reg statement....nothing > has worked yet. > > When I use look at the technology mapping from Synplicity, it doesn't show > what flops are IOB flops...when I bring up the .ncd file (pre PAR) in > Floorplanner...the FF for one of the two destination registers is already > in the IOB...but it's the wrong one... > > So, how do I tell Synplicity (preferably) specifically which flop I want in > the IOB? > >Article: 28161
Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote in article <lt4rzwi2kh.fsf@mis.dtek.chalmers.se>... > "Austin Franklin" <austin@darkroo98m.com> writes: > > > I have an input that has two flops for destinations. I want one of them to > > be in the IOB, and the other flop to use a CLB flop, and the tools do > > that....but it's the wrong one that ends up in the IOB. > > * Watch out for setup and hold timing. > * You could use UCF to specify IOB TRUE, and turn it off in Synplify. Getting the flops that are being clocked by the faster clock in the IOBs is the goal... Setup and hold times on the slower clock flops are handled by inverting the clock....that gives plenty of setup and hold. Thanks!Article: 28162
> You could use the xc_props attribute from Synplify to tag the flops with the > appropriate Xilinx attribute IOB = (TRUE|FALSE). That is what I ended up doing...and confirmed it does work. Thanks! > The following example should do what you are asking for (note that I had to > use the syn_preserve attribute so that all the flops don't get merged): Yep, I found out a while ago about that I needed to use syn_preserve in this situation ;-)Article: 28163
In article <3A442CBC.3A9401F8@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > This question comes up more often than most of us care to admit. The bitstream [ snip ] Hi Thanks for taking the time to respond to my question. I appreciate it. David Sent via Deja.com http://www.deja.com/Article: 28164
"Austin Franklin" <austin@darkroo98m.com> writes: > Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote in article > <lt4rzwi2kh.fsf@mis.dtek.chalmers.se>... > > "Austin Franklin" <austin@darkroo98m.com> writes: > > > > > I have an input that has two flops for destinations. I want one of > them to > > > be in the IOB, and the other flop to use a CLB flop, and the tools do > > > that....but it's the wrong one that ends up in the IOB. > > > > * Watch out for setup and hold timing. > > * You could use UCF to specify IOB TRUE, and turn it off in Synplify. > > Getting the flops that are being clocked by the faster clock in the IOBs is > the goal... Setup and hold times on the slower clock flops are handled by > inverting the clock....that gives plenty of setup and hold. Thanks! Ah, you are lucky! You have a _slow_ clock. I always seem to have a fast clock and then smoe faster... ;-) Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 28165
Ray Andraka wrote:
>
> It is possible, however I strongly recommend you use an external pullup. The
> internal pull ups are weak pull ups sufficient to tie an unconnected pin high.
> However when that pin has a trace and loads attached, the pull up value is
> really too small to ensure a) that the trace does not act as an antenna and b)
> that the open drain output goes back high in a reasonable amount of time. The
> high impedance (>100K) of the internal pullup does little to guarantee this.
t = rc = 100x10^3 x 20x10^-12 (quite liberal)
= 2 us
2.2 rc (10%-90%) == 4.4 us
tr (virtex, xqr4000xl) max = 250 ns
==> external pullup. don't know spartan xl, original question.
for those of the actelian persuasion, tr (sx-a) max = 50 ns.
----------------------------------------------------------------------
rk How the hell do I know? I'm just a
stellar engineering, ltd. common, ordinary, simple savior of
stellare@erols.com.NOSPAM America's destiny.
Hi-Rel Digital Systems Design -- Pat Paulsen
Article: 28166We were having a very strange problem after power-up (intermittently, maybe 1 of every 8 power cycles) where an XC2S150 would not respond to PROG/ and thus could not be configured. The device would release INIT/ even though PROG/ was still asserted, then INIT/ would stay high despite several high/low cycles of PROG/. We even tried cycling CCLK continuously (watching for INIT to go low again when it detected bogus config data) with the theory that the device came up in the wrong config mode and hadn't totally lost its brains. We suspected power sequencing problems from the beginning, and we were right. The 3.3V VCCO supply would ramp up from 0 to 95% in about 12ms. The 2.5V VCCINT supply (regulated on board from 5V) would ramp up very quickly from 0 - 95% (~250us). The 3.3V supply was slightly above 1V (the level required for configuration) when the 2.5V supply reached 95%. We ended up eliminating the problem by delaying the 2.5V power-up by several milliseconds, but the ramp up was still very quick (much faster than the 2ms recommended in the Spartan-II data sheet). The problem has been eliminated, but I want to understand the mechanism. Anyone know what may have been going on inside the device that would cause it to release INIT/ with PROG/ still low and then ignore all future assertions of PROG/? The only way to clear the condition was to cycle power. Thanks, Bob SeftonArticle: 28167
David, let me talk you out of what you seem to be trying. The vast majority of the bits in the bitstream has a specific function, activating a pass transistor, controlling a multiplexer, driving a metal line etc. ( A few bits are just left-over fill bits, but only a few) If you start "evolving" bitstreams, you will most likely create massive contention on the chip, i.e. two opposite signals driving the same piece of metal. Although the individual contention current may be just a few mA, multiple thousands can literally melt down the plastic package and destroy the chip. Xilinx used to make the XC6200 chip that did not have multiple outputs able to drive the same line, so it was bullet-proof, and it became the darling of experimenters like you. Unfortunately, XC6200 did not find a home in commercial applications, so we stopped making it. If you want to put evolving bitstreams on any Xilinx ( or Altera or Atmel) FPGAs, don't do it ! I copied Delon Levi here at Xilinx who may have additional thoughts. Peter Alfke, Xilinx Applications ================================ longwayhome@my-deja.com wrote: > Hi > I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on > it. With the board came a utility which can send compiled bitstreams to > the chip. I'd like to manually generate the bitstreams though, rather > than compile them from a vhdl spec though, as my intention is to > program it using evolutionary algorithms and I think this would be > easier and faster than actually generating vhdl and compiling that then > sending that to the chip. > > Does anyone know where I can find a spec which would show exactly how > the bitstreams are interpreted by xcv100 ? I've already had an > unsuccessfull look at the Xilinx site (but i've had problems finding > what i want there before...) > > I'm a complete beginner at this, all advice greatfully accepted. > > Thanks > > David > > Sent via Deja.com > http://www.deja.com/Article: 28168
"Theron Hicks" <hicksthe@egr.msu.edu> wrote in message news:3A37CD2C.21969FDB@egr.msu.edu... > Can anyone give me the "best" way to implement a _fast_ counter in a > SpartanXL design? I need a 16 bit counter with enable and reset.clock > on negative edge preferred but not critical. I don't need the output to > be synchronous because I am counting to measure pulse width so I can > wait for the final result to ripple through to the output. The _only_ > factor of importance is _speed_. Should I use logiBLOX or should I > write my owm or should I forcibly implement it using some unknown (to > me) tool? I need to get up to 204.8MHz toggle frequency. The output in > counts will be latched after the pulse is completed and the resulting > count values will be passed through a tri-state output of some sort. > > Thanks, > Theron J. Hicks > The fastest counters in my experience are LFSRs (linear feedback shift registers) - the outputs aren't binary and you only get (2^n)-1 states (all zeros aren't valid), but these are basically shift registers with an xor feedback term and they use the fast carry logic. Maybe you can get software to do the reverse conversion if that is not in the critical path. Search Xilinx website for LSFRs. Mark.Article: 28169
On Wed, 22 Nov 2000 15:36:05 +0100, "Jurjen Boss" <jboss@lmint.com>
wrote:
>Hi,
>
>We want to implement a Xilinx Spartan-II FPGA, type XC2S50, in our
>(excisting) application. I'm trying to estimate the current supply of this
>device by using the datasheets ("Spartan-II 2.5V FPGA Family: DC and
>Switching Charateristics"). From this datasheet I get the following
>information:
>- Iccintq = 50mA; (supply current internal part)
>- Iccoq = 2mA; (supply current I/O-part)
>- Iccpo=500mA; (ramp rate 2ms)
>
>Does this FPGA needs so much current at power-up? How can this ramp rate be
>adjusted? I just can't imagine that this FPGA needs 500mA at power-up. I
>thought these devices where low-power!?! Is there some information available
>on this subject?
>
>Regards,
>
>Jurjen
>
Jurjen,
At low supply voltages, before all the CMOS gates have made up their
minds to be hard high or low, all sorts of P and N-channel FETS can be
conducting. This can draw lots of current. If your supply can muscle
past this point and pull Vcc up to the rated voltage, good; if not,
the supply can current limit and the system can hang.
Most CMOS parts behave this way.
John
Article: 28170markp wrote: > The fastest counters in my experience are LFSRs (linear feedback shift > registers) - the outputs aren't binary and you only get (2^n)-1 states (all > zeros aren't valid), but these are basically shift registers with an xor > feedback term and they use the fast carry logic. Maybe you can get software > to do the reverse conversion if that is not in the critical path. Search > Xilinx website for LSFRs. > . I disagree ( and I am the one who wrote the Xilinx app note on LFSRs. :-) LFSRs are the fastest synchronous counters, since they do NOT use the carry chain, but just an XNOR feedback. (XNOR makes all-zero legal, but skips all-ones, a better choice.) There is even a fairly simple trick to make an LFSR go through all possible states. LFSRs were more popular before Xilinx and Altera incorporated fast (ripple-) carry logic in their FPGAs. The counter that resolves the highest frequency is a simple ripple counter, where only one flip-flop has to toggle at the max rate. I built a 420 MHz BCD-ripple counter 3 years ago, and will soon try to do an even GHz in Virtex-II. Obviously, there is a ripple delay, so that you have to wait "awhile" before you strobe the result into anything. BTW, the LFSR is also the champion high-power consumption counter, with statistically 50% of its flip-flops changing state on every clock tick. Synchronous binary is much better, and ripple binary is best. Peter Alfke, Xilinx ApplicationsArticle: 28171
In article <3A45264E.F4FBE995@xilinx.com>, peter.alfke@xilinx.com wrote: > David, > let me talk you out of what you seem to be trying. Oh dear :-) > Xilinx used to make the XC6200 chip that did not have multiple outputs > able to drive the same line, so it was bullet-proof, and it became the > darling of experimenters like you. > Unfortunately, XC6200 did not find a home in commercial applications, so > we stopped making it. Yes, someone recommended me to get one of those chips, however I learned you weren't producing them anymore (and didn't know why they had become so 'legendary' in this use anyway). > If you want to put evolving bitstreams on any Xilinx ( or Altera or Atmel) > FPGAs, don't do it ! What I was planning on doing (correct me if i'm way out of line here, which is fairly possible) was taking each 'cell' on the fpga (in a given area, for example an area of 20 x 20 cells) then having some simple rules which i'd follow, deciding what the purpose of a given cell was to be (within the rules, eg only one output to drive a given line) then i'd take this meta design (arrived at through an evolving algorithm) convert it to the bitstreams and pass the bitstream to the chip using the xsload (comes with the Xess cdrom) where it would be evaluated. However i'd need to find out what each bit for a cell specified which I could then use to transfer my meta design to a bitstream - is it possible to get this info [i'm just a hobbyist, no danger of me seeking to get any competitive advantage over xilinx i can assure you :-)] I didn't actually want to treat the bitstreams themselves as a piece of 'dna' to mutate/breed etc although now that you've mentioned that idea an XC6200 board would be a nice thing to have (if xilinx have any such boards lying around destined for wastage... :-) Thanks for your warning though. Can you can help with that cell programming info, or suggest any other way of approaching this problem ? (i'm _really_ desperate to try this evolving hardware thing...) David Sent via Deja.com http://www.deja.com/Article: 28172
How does this Aldec Active HDL compare to Mentor's FPGA Advantage 4.0 ? FPGA Advantage is quite nice as well. In article <sWx%5.73920$58.9187280@typhoon.tampabay.rr.com>, "S. Ramirez" <sramirez@deleet.cfl.rr.com> wrote: > Swift, > I have and use Aldec's Active-HDL 4.1 simulator for all Verilog and VHDL > designs, except when a client company insists that I use their simulator > tool. Some of these tools have sign-off capability; however, I don't need > anyone signing off on my FPGAs! > Of all of the simulators, it has a great Windows GUI, and it seems to be > the only simulator with a Windows GUI designed from the ground up. Other > simulators seem to be "Windows-like," i.e., they seem to be adapted from > Unix or DOS based designs. > I have used it to do simple to complex designs with relatively little > problem. I had a problem once with 4.0, and their support department jumped > right on it. Problems are normal for all products, it seems, and the true > differentiator, is tech support. > You will not go wrong with Active-HDL 4.1 and Synplicity. Those are > the tools I use, and they are great! > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL, USA > > "Swift" <jboss@wxs.nl> wrote in message > news:91iv1c$1jh9f$1@reader2.wxs.nl... > > Does anyone use this tool for simulating VHDL-stuff for a FPGA? What's > your > > opinion? Any other suggestions? We need a tool only to simulate a > > VHDL-design. We already use Synplicity to synthesize. > > > > THX, > > > > JB > > -- Hien Pham San Francisco, CA Sent via Deja.com http://www.deja.com/Article: 28173
On Sun, 24 Dec 2000 00:29:06 GMT, longwayhome@my-deja.com wrote: >Thanks for your warning though. Can you can help with that cell >programming info, or suggest any other way of approaching this >problem ? (i'm _really_ desperate to try this evolving hardware >thing...) I have an idea on on this. I think it should be possible to write an EDF as the output of your genetic algorithm and go through the P&R (you can use the command line tools for full automation). If you can also generate the placement with your tool (actually the placement is already fixed; you just need to generate the behaviour of each individual LUT) the P&R should be quick. This might prevent you from programming the FPGA to reprogram itself, i.e. you can't put the growth algorithm into the FPGA and get it to reprogram itself. The pc/workstation has to be in the feedback loop. I think this is a much easier project than reverse-engineering the bit file. hope this helps, Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 28174
On Mon, 18 Dec 2000 02:39:05 GMT, bobdittmar@my-deja.com wrote: >When selecting which one is "better" you should also keep in >mind what your verification strategy is. I find verilog to be good >for doing behavioral modeling of my test objects : processor bus >models, data packet generators/monitors etc that reside in the >testbench and are "wired" to the FPGA under test. Without PLI Verilog is quite difficult language to use for really complex behavioral models. The Verilog language itself is quite restricted, for example file i/o is poor compared to VHDL (altough it's easier to use in Verilog). Also without real data types complex behavioral models are not fun thing to do. For verification I would suggest new verification languages (Vera, e). I have used Vera quite extensivly and wouldn't go back easily to HDL languages in testbenches. I can't even think of writing 30-40k lines of complex TB code in some HDL language :) Object orientation speeds up the TB-design considerably. >I'm not real VHDL literate but I have not seen this same testability >in VHDL. You should propably read some VHDL book. VHDL was originally designed for system modeling and is quite strong language in modelling. Only small part of the language is used in synthesizable models. -- ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Iirislahdentie 47 E | IRC: embo | curved-space fault in 02230 Espoo,Finland | | write-only file system
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