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
"Arash Salarian" <arash dot salarian at epfl dot ch> skrev i melding news:3efaef99$1@epflnews.epfl.ch... > Hi, > > What's your suggestion for a low-power, battery operated FPGA design? What > family do you suggest? I guess the design should need something like 20K~30K > gates (yeah, I know this does not all that correct but I've not syntesized > the design yet and can't give a good estimate on number of LEs or FFs...). > From what I've seen in data-sheets, besides the power consumption, one major > concern is the power-up and configuration current for SRAM based devices. > Also I'd like to have the minimum number of VCC voltages on the board and > other parts used in the design are 3.3v and can be safely run using a single > rechargable battery with no need for DC-DC converter circuit (it means that > they can work from 2.7v to 4.1v with no problem). I would check out the Xilinx's Coolrunner family (1.6-3.6v)Article: 57251
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:uk7b9z2w8.fsf@trw.com... > "Patrick MacGregor" <patrickmacgregor@comcast.net> writes: > <snip> > > I also can't buy into the HDL argument. The reason is simple. If you were > > a software developer and you needed your code to be as small as possible and > > run as fast as possible, what language would you use? Well, every software > > developer I've ever met answers the same -- native assembly language for the > > processor in question. No compiled code will be more efficient because of > > the layers of abstraction that higher level languages impose. The embedded > > developers I've worked with always got a good chuckle out of their C > > language counterparts sucking up 100's of kilobytes of memory compared to > > the few K that their assembly code needed. > > > > The point as already been made that very few people write the whole > thing in assembly. > > > HDL is the same. You abstract designs (so that non-designers can pretend to > > be designers I suppose) and pay a penalty by having circuit bloat. If you > > want the smallest design possible, and want it to run as fast as possible, > > you need to use the design equivalent of assembly coding -- i.e. schematics. > > A picture is worth a thousand words, so you can make a picture or type a > > thousand words. Which one will be easier for someone else to understand, > > hmm? > > > > HDL doesn't force abstration - you can write gate-level HDL. There > are illustrious people populating this group who frequently do the > "design equivalent of assembly coding" in HDL. HDL by its very nature is abstraction in the same way that C abstracts from assembly. You describe logic and let some piece of software try to figure out what it means. > > Come to think of it, last time I did a schematic I used the > "abstraction" of a counter block, which hides flops inside it. Only > if you know how to make a counter do you know "where every flop is". > And that's the same in HDL - I know I've written code that will mean a > counter gets built, so I know what flops there are there. > Hierarchies are not abstractions. Punch down into the counter to see the design. Sadly, these days it will probably be an HDL, so if a newbie wants to learn about counter design, it won't help any. I've used numerous counter types to solve different prolbems. T-FF based, Johnson counters, D-FF based. Each has a place if you know how they are built and what their tradeoffs are. > <snip> > > > > > With a schematic it is sooooo simple to identify each and every flop and see > > what it is doing in a simulation. Something isn't working in HDL? Good > > luck. Oh yeah, and with schematics, you never have to do all that modeling > > nonsense. While most "designers" are modeling what their circuit is > > supposed to do, I've already got it done, simulated, verified on the bench, > > off my plate and onto the next thing. > > > > What do you do when your two BGA packages aren;t talking to each other > and you haven't got the chance (because of signal integrity concerns) > to put a probe point on the board? I use any number of debugging methods to solve board problems. Generally though, I find that if I simulated it properly, it works in circuit (barring fabrication problems or layout errors). If it doesn't work in circuit, usually it means I missed some condition in the simulation. > > I go back to my simulation, with its models and all that 'waste of > time'. > > Another advantage of this approach is that I can write a testbench > that covers all my (many) testcases and reports a pass or fail at the > end. That way I can modify any code I like and know I haven't > recreated any old bugs. Not quite so easy when staring at > waveforms... > Well, I guess we mean different things when we describe "simulations". The Quartus tools allow me to simulate the design without having to "model" anything. I can take the actual design and throw signals at it directly to see if it is doing what it should. If I've built the circuit according to the timing diagrams, I should see resultant waveforms that match what I expect. Very simple to follow visually, and it has the added benefit that you see a lot more about what is going on in the circuit instead of a simple "pass/fail". BTW, with waveforms you can also do pass/fail tests really, really easily and automatically. There is no penalty from using waveforms, but there is a lot to gain. Also, when you debug the board, you should be able to match appropriate I/O signals with ones witnessed in simulation. Seeing a blinky light turn on doesn't mean a circuit worked. You have to know how well it is working, and know what the signal integrity is along the way. This usually means o'scopes, which means, you guessed it, waveforms. > <snip> > > Just some thoughts from the other side! > > Cheers, > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt, Solihull, UK > http://www.trw.com/conektArticle: 57252
SpartanXL is my suggestion, Austin Arash Salarian wrote: > Hi, > > What's your suggestion for a low-power, battery operated FPGA design? What > family do you suggest? I guess the design should need something like 20K~30K > gates (yeah, I know this does not all that correct but I've not syntesized > the design yet and can't give a good estimate on number of LEs or FFs...). > From what I've seen in data-sheets, besides the power consumption, one major > concern is the power-up and configuration current for SRAM based devices. > Also I'd like to have the minimum number of VCC voltages on the board and > other parts used in the design are 3.3v and can be safely run using a single > rechargable battery with no need for DC-DC converter circuit (it means that > they can work from 2.7v to 4.1v with no problem). > > Best Regards > ArashArticle: 57253
Patrick MacGregor wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:3EFA9377.E87AB5E7@yahoo.com... > > Patrick MacGregor wrote: > > > > > > Amen brother! > > > > > > The "pay" tools are essentially the same, and work just as deplorably. > I > > > have a copy of ISE 5.2, and it uses the same sorry excuse for a > schematic > > > editor. I invented the "hexplitive", which was swearing in base 16, > when > > > working with X schematic tools. > > > > > ...snip... > > > I also can't buy into the HDL argument. The reason is simple. If you > were > > > a software developer and you needed your code to be as small as possible > and > > > run as fast as possible, what language would you use? Well, every > software > > > developer I've ever met answers the same -- native assembly language for > the > > > processor in question. No compiled code will be more efficient because > of > > > the layers of abstraction that higher level languages impose. The > embedded > > > developers I've worked with always got a good chuckle out of their C > > > language counterparts sucking up 100's of kilobytes of memory compared > to > > > the few K that their assembly code needed. > > > > But you ignore the fact that very few embedded engineers need their code > > to be "as small as possible" or "fast as possible". That is because the > > hardware gives lots of head room for very few bucks. Likewise FPGAs > > generally are more than fast enough and large enough and cheap enough > > (did *I* say that?) for 95% of the designs to be done in HDL. > > > > In 20 years in this business (primarily telecom/datacom), I've never once > had a situation where bloat was allowed. Bloat = added cost that doesn't go > away. You burden every finished product with unecessary cost simply by poor > design practices. A few dollars difference in parts doesn't mean much when > you build 10. But when you built 100,000 it suddenly means a lot. I've had > to sweat R's and C's many times, trying to remove as many as possible, and > then try to make the remaining ones use similar values as much as > possible -- all to try and minimize costs (cost of parts, cost of time for > the person ordering different parts, cost of warehousing -- it all counts if > you think about it). If you are in Telecom then you must have used TTC (now Acterna) test equipment. If so, I can assure you that you have worked with bloated software. This was done to facilitate the modularity of the hardware (which also had to be more complex than actually required) and subsequently was harder to maintain. Not only did they use C, but they used C++. Clearly assembly was not needed, and the C and C++ had advantages in time to market or why would they use it? > Having recently done an OC48 framer design (in a couple of weeks), I could > have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I > aimed for a 1C3 part in the slowest speed grade. Works just fine, using > about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not > "expensive". Choosing to design efficiently added exactly zero time penalty > but yielded tremendous cost savings. If you only used 1/3 of the LCs, then surely it would have fit using an HDL. If you don't know how to use an HDL, then you can produce some pretty poor code that is much larger than needed. It is another animal to learn, but can improve your efficiency. BTW, the fact that you did not even fill half of a 1C3 supports my statement that you most likely do rather small designs. The advantages of HDLs show when you start making larger chips. > > Again for the same reason that few designers do an entire project in > > assembly, I won't be doing any more schematic designs. The last one I > > did was a PITA to draw the gates needed for FSM design or worse, address > > decoding. Data path is not bad in schematic, but the random logic is no > > fun at all and it takes up so much space when you try to view a large > > design. I don't mean disk space, I mean viewing space. I can view an > > equivalent project in a text editor much more easily than a schematic > > editor. > > > One startup I worked for had an embedded designer assigned to one or more > ATM interface cards. These guys wrote in assembly only, and because of this > were able to keep up with ATM at OC-3 rates using a very slow, primitive > (i.e. inexpensive) micro. > > The fact that random gate design being "no fun at all" and "taking up a lot > of space" suggests a few things to me. First, there are some simple rules > for making a clean, legible schematic. Too bad schools never teach them. > Also, I firmly believe that nearly anyone can make a functioning design > given enough time. This doesn't make it a good design. Some designs are > better than others, and one way to get to the "good design" stage is to get > your fingers into the gates and learn how to work with them efficiently. > > I regularly test whether or not an HDL can create logic more efficiently > than me. It can't. Not once has it implemented any type of decoding > function better than I can. It can match me in terms of resources utilized, > but it can't best me. By staying in the gates, I always have an instant > grasp of how large a design is getting. I stopped one major piece of that > OC48 design simply because it was getting too large. I knew that because I > could see it on the page and in the floorplanner. Seeing the size forced me > to think about other ways to implement the process. The first way worked, > but so what? Not good enough. I needed to reduce the size to stay > comfortably in the smaller part. You are missing the point. The HDL tool will not make more efficient logic, but it can do well enough. Engineering is all about doing the job to spec and within schedule. Trying to get your gate count lower is a waste of time. That is the sort of stuff that kids did in school, to make a design run even faster or make it smaller. Sure these are good learning exercises, but in engineering the emphasis is on spec. HDLs do a "good enough" job 99% of the time. > > > HDL is the same. You abstract designs (so that non-designers can > pretend to > > > be designers I suppose) and pay a penalty by having circuit bloat. If > you > > > want the smallest design possible, and want it to run as fast as > possible, > > > you need to use the design equivalent of assembly coding -- i.e. > schematics. > > > A picture is worth a thousand words, so you can make a picture or type a > > > thousand words. Which one will be easier for someone else to > understand, > > > hmm? > > > > There are lots of reasons to use HDLs, but trying to enable uneducated > > hardware designers (or worse, software designers) is not one of them. I > > feel that to properly use an HDL you need to know what you expect for > > hardware and then describe that in the HDL. But again, very few people > > have to have the "smallest" or the "fastest" design. Mostly they have > > goals which include schedules. > > > The best HDL folks I know are ones who use it like it was a schematic. So, > in my mind, why bother? And again, I've never had the luxury of NOT needing > the smallest/fastest design. It's how I push 4 OC48s through a $30 part, > saving a client millions on NOT needing to buy a bunch of expensive ASSPs > for every board. > > Size does count, and I can proudly say that "mine is smaller than yours". > ;-) Interesting idea of what constitutes "good" or "best". I once worked at TRW where I learned one very valuable lesson. An optimized system is more expensive in all areas of design. It is more expensive to design initially since it takes more time. It is more expensive to test since it is more complex. It is more expensive to maintain since a change is harder to make without breaking something else. A smaller design is likely going to be more expensive to engineer over the long haul. Unless you actually get into a smaller chip and save money, you have done nothing useful. > > As to the picture and word analogy, I find the words to suit design > > better. It takes a large picture and a lot of time to create it, to > > equal those thousand words. > > > Some folks are visual and some folks prefer the written word. I'm obviously > visual for circuits and have no problem using the written word, like now, > for example. Seeing and creating are different. Nearly all people can understand a good drawing more easily. That is why all my HDL designs start with block diagrams. But turning that into a complex design in schematic is a PITA. Once you get used to code you will find that it is much easier to work with... or not. Your preference. > > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% > of > > > the designs he has seen are done in schematics. You can even read about > > > graphical versions of HDL coming out. Sounds like schematics to me. > Except > > > that you add a layer of obfuscation in there that will make for a more > > > bloated design. Why bother? > > > > I don't know where you got this, but this sounds like an exaggeration. > > I would say he had it backwards, but I bet the schematic usage is less > > than 20%. > > > I got this right from the horse's mouth. I didn't make it up. It was his > observation of designs he's seeing. Why would he lie? He has no vested > interest in any method his clients use. Simply the stats he sees. I can assure you that this is not true for design starts today. If it were there would be a lot more postings here from people who use schematic. There are virtually none, perhaps what, 1 a month other than threads like this? > > > An ironic thing to notice is that if you open many of the X design > examples > > > included with the tools, you'll see that they are schematic based. > > > > > > With a schematic it is sooooo simple to identify each and every flop and > see > > > what it is doing in a simulation. Something isn't working in HDL? Good > > > luck. Oh yeah, and with schematics, you never have to do all that > modeling > > > nonsense. While most "designers" are modeling what their circuit is > > > supposed to do, I've already got it done, simulated, verified on the > bench, > > > off my plate and onto the next thing. > > > > If you don't feel the need to simulate, then you are clearly doing very > > simple designs. The simulation is to make sure you are solving the > > problem rather than just knowing what you are creating. These are two > > different problems. > > > Guess you missed it when I said I simulated the designs, right before > testing them on the bench. I never skip simulating. Again though, I prefer > the graphical waveform version as I get to see a nice, pretty picture of > what is happening and when. It is very simple to pull up any flop in the > design and see it relative to anything else. Makes debugging go 10 times > faster. And, once I'm happy with it, I can transfer the simulator results > back into the input file so that I can compare expected to generated results > should I make changes or add new stuff. What could be simpler? Then what are you talking about by "modeling"? If you think waveform editing is the way to go in simulation, you are missing the best part of an HDL. Even if I had a design in schematic I would want to simulate it in an HDL simulator. Being able to code the environment makes life so much easier than creating waveforms. That alone is worth using an HDL in my opinion. > > > I was taught the power of schematics and their companion, the timing > > > diagram, when I was a wee engineer pup. My first boss would sit me down > and > > > go over the schematics with me, asking me to justify each and every > > > component on the page. If there wasn't a good reason for it, it was > gone. > > > Amongst the many invaluable lessons he taught me was that every > component in > > > the circuit should have a reason. Try doing that with an HDL > abstraction. > > > Most "designers" haven't a clue how that hunk of code they wrote got > > > implemented in actual gates. Scott Adams would probably call them > > > "Duhsigners". > > > > > > <getting off soapbox now> > > > > > > So, I'm with you 100%. Schematics rule. Xilinx has no reason > whatsoever to > > > support schematics, as the bloated designs that HDLs produce force folks > > > into buying larger, faster speed grade parts that are naturally more > > > costly. Works for them. > > > > > > You can always download the free Altera tools and play with their stuff. > > > Fully integrated schematic capture, compiler and simulator. Very nice. > Not > > > perfect or bug free, but then no tool is. It is, however, VASTLY > superior > > > to the X garbage schematic tools. > > > > > > When I need to design something in an X part, I do it first in the A > tools > > > and use their native simulater. Then I re-enter it in X. Doing the > > > drawings twice is STILL faster than doing the design from scratch in X. > Try > > > it. > > > > > > I tend to always push my clients to use A parts simply because the tools > are > > > so superior. Design times are radically reduced, and that saves them > > > tangible money. If they insist on X parts, I revert to the paragraph > above. > > > > > > Don't buy into the HDL propaganda. Schematics will never do you wrong. > > > > No, but they will take more time and make large jobs nearly impossible. > > For the duhsigner, perhaps. Personally, I've never found any job too large > for schematics, whether doing ASICs or FPGAs. And, you need schematics to > design PCBs, so the extra practice doesn't hurt. What ever works for you. But most people have learned to use HDLs efficiently, just as most programmers (even the best ones) have learned to use C effectively. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57254
say we have LUT into the .XDL file that is: (the slice is for example CLB_R18C30.S0) G:dev/TIMER/un2_r_counter_348:#LUT:D=(A1*(A2*(A3*A4))) A LUT is basically a RAM with a 4bits address access so that the corresponding LUT should contain: 0x8000 because only one bit should be set to '1', the one pointed by address 0xF. Correct? Now I want to change some constant and my new logical equation is for example D=(A1+A3). What if I parse the .BIT and write (jbits or similar) at the accurate location 0xCCFF?Article: 57255
Paul Urbanus schrieb: > I have a design that I did almost 15 years ago that fits in a 20L10 PAL. > This was written in ABEL, a PALASM like language, that was created by > Data IO (now Synario). > > I need to port this design to a 22V10, because these parts are more > readily available. ... > I'd prefer to use ABEL, because that would require the minimum amount of > design changes. Does anyone know if there are any old versions of ABEL > (by Data IO, now Synario) that have been released into the public > domain? If not, can anyone recall what form of copy protection, if any, > was used on the old DOS versions. have a look at "isp lever starter" from Lattice its free abd will do the job includiding programming the parts there is also ABEL in DOS Version around, i think it is "defacto" public domain meanwhile greetings, Bertram -- Bertram Geiger <bgeiger@aon.at> HTL-Bulme Graz, AustriaArticle: 57256
Arash Salarian wrote: > > Hi, > > What's your suggestion for a low-power, battery operated FPGA design? What > family do you suggest? I guess the design should need something like 20K~30K > gates (yeah, I know this does not all that correct but I've not syntesized > the design yet and can't give a good estimate on number of LEs or FFs...). > From what I've seen in data-sheets, besides the power consumption, one major > concern is the power-up and configuration current for SRAM based devices. > Also I'd like to have the minimum number of VCC voltages on the board and > other parts used in the design are 3.3v and can be safely run using a single > rechargable battery with no need for DC-DC converter circuit (it means that > they can work from 2.7v to 4.1v with no problem). > > Best Regards > Arash I don't think you are going to find any programmable logic to run off of a 2.7 to 4.1 volt supply other than possibly 22V10s. So the first requirement I would recommend that you toss is the wide voltage range. Use a regulator. Then the job gets easier. You can check out the Coolrunner (XCR3xxxXL) CPLDs from Xilinx. They run on 3.3 volts and are very low power. Being flash based, you don't have to worry with configuration at run time. But they can be changed by a micro if need be. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57257
"Paul Urbanus" <urbpublic@hotmail.com> wrote in message news:3EFAF38B.3030504@hotmail.com... <snip> > After I port the design, I'm going to release it > into the public domain so enthusiasts of this machine can modify it if > they want. </snip> To flavor your pursuit . . . how many enthusiasts would want to build something with 22V10s? I'd have to dig up the old programming hardware and ancient tools to get those PALs programmed. I can program CPLDs and FPGA configuration ROMs with JTAG, hooked up to the parallel port through a simple circuit to connect to the FPGA vedors' programming drivers. Perhaps more enthusiasts would be willing to go this route.Article: 57258
"Jay" <yuhaiwen@hotmail.com> wrote in message
news:bde3rr$rs8gp$1@ID-195883.news.dfncis.de...
<snip>
> How can I simulate this modules? in testbench I tried to initiate the
> clkout, but failed.
</snip>
If you're doing RTL simulation from your original code, you need to
initialize all your variables for simulation such as
initial
mydesign.clkout <= 1'b0;
Alternatively, post place and route simulation can give you proper
initializations as long as you bring out the global set/reset signal (.GSR)
when generating the verilog file from the Xilinx tool. Then, the "initial"
block doesn't initialize the individual RTL registers but is used to drive
the .GSR for a short time at the start of the simulation, initializing all
the register primitives to the power-on values. I don't recall if memories
still need manual initialization or not (since they aren't cleared by a
reset but are loaded with the programming file).
The advantage to post place and route simulation is that some of your
registers may power up logic high (when an FDS or FDSE primitive is used to
implement the synthesized logic) and an incorrect initial state can alter
your device's performance.
Article: 57259Not surprisingly, I agree with Austin. SpartanXL is technically identical with XC4000XLA, but is a younger part. It is the "last bastion" of truly low standby or idle current, actually (typically) much lower than the guaranteed specification ( 100 uA would be my guess). It uses one Vcc=3.3 V, and it is 5-V tolerant. The archtecture is "ancient" by FPGA standards ( i.e. 8 years old). It has carry and distributed RAM, but no BlockRAM, no multipliers and no fancy clock management, but if it does your job... Peter Alfke, Xilinx Applications ==================================== Austin Lesea wrote: > > SpartanXL is my suggestion, > > Austin > > Arash Salarian wrote: > > > Hi, > > > > What's your suggestion for a low-power, battery operated FPGA design? What > > family do you suggest? I guess the design should need something like 20K~30K > > gates (yeah, I know this does not all that correct but I've not syntesized > > the design yet and can't give a good estimate on number of LEs or FFs...). > > From what I've seen in data-sheets, besides the power consumption, one major > > concern is the power-up and configuration current for SRAM based devices. > > Also I'd like to have the minimum number of VCC voltages on the board and > > other parts used in the design are 3.3v and can be safely run using a single > > rechargable battery with no need for DC-DC converter circuit (it means that > > they can work from 2.7v to 4.1v with no problem). > > > > Best Regards > > ArashArticle: 57260
There are more enthusiasts who would use 22V10s than you would guess. In
this case, the PALs are in an existing peripheral card. If the
enthusiast wanted to change the functionality of the peripheral, it
would be a relatively simple matter to modify the PAL code.
And, many of the cables for programming ISP-capable 22V10s are nothing
more than TTL buffers connected to a parallel port. So, these are easy
for the hobbyist to build.
John_H wrote:
> "Paul Urbanus" <urbpublic@hotmail.com> wrote in message
> news:3EFAF38B.3030504@hotmail.com...
> <snip>
>
>>After I port the design, I'm going to release it
>>into the public domain so enthusiasts of this machine can modify it if
>>they want.
>
> </snip>
>
> To flavor your pursuit . . . how many enthusiasts would want to build
> something with 22V10s? I'd have to dig up the old programming hardware and
> ancient tools to get those PALs programmed. I can program CPLDs and FPGA
> configuration ROMs with JTAG, hooked up to the parallel port through a
> simple circuit to connect to the FPGA vedors' programming drivers. Perhaps
> more enthusiasts would be willing to go this route.
>
>
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
<><><><><><><> The Worlds Uncensored News Source <><><><><><><><>
Article: 57261On Thu, 26 Jun 2003 10:08:20 -0400, Patrick MacGregor <patrickmacgregor@comcast.net> wrote: > > "Thomas" <tom3@protectedfromreality.com> wrote in message > news:oprrcygwqomo2d8p@news3.news.adelphia.net... >> I read with interest your thoughts about hdl vs schematics and the > parallel >> with software >> I've developped software for 14 years and while at heart I agree with >> you, >> in my day to day practice I disagree. Assembler will always provide you >> a >> most optimized solution, but C/C++ is much faster to develop with and is >> more accessible; btw, that's assuming you have competent engineers >> writing >> assembler, otherwise it turns into a mess very quick. yes, you definetly >> lower the efficiency of the resource usage with a higher level language, >> but nowadays it is cheaper to get faster / bigger hardware than more >> engineers / time. >> the days where we used to build things right are over; now the key is >> how >> fast you can put something on the market; it's sad, but the tech >> industry >> is not what it used to be. >> I have never been too much in touch with the hardware industry, but >> lately >> it has changed and I realize that you guys have the exact same issues / >> concerns / problems / etc we have in software; kind of ironic, in a sad >> way. >> >> Thomas. > > The assembly level guys I've worked with were every bit as fast as their > C > counterparts when developing code. If you do it a lot, you get good, > fast > and efficient at it. And as with HW design, you create a bag of tricks > you > employ to speed the next jobs along, as well as developing a library of > previously designed pieces you can employ later. > > There is just no reason why you can't design quickly and correctly at the > same time. That is one key difference between a newbie and someone with > a > lot of experience. It is then incumbent on the experienced folks to pass > along knowledge to the newbies to speed their development into capable, > competent designers. Nothing beats experience. > > I agree on the experience part, but I disagree about the speed to write code, the difference is massive; just the amount of typing alone is radically different; optimizing assembler by hand is not trivial anymore; if you optimize math for example, it takes a fair amount of time to produce code faster than compilers nowdays; the result will be greater, but will your product be? is it worth the cost? usually not at all. I work in the video game industry, we're still using assembler a lot, but only on very small and select pieces of the products, it is not worth doing it more; it costs too much in time, it requires a more skilled (expensive) team, etc and the end result is not different enough to warrant the costsArticle: 57262
In article <oprrdtyor4mo2d8p@news3.news.adelphia.net>, Thomas <tom3@protectedfromreality.com> wrote: >> The assembly level guys I've worked with were every bit as fast as >> their C counterparts when developing code. If you do it a lot, you >> get good, fast and efficient at it. And as with HW design, you >> create a bag of tricks you employ to speed the next jobs along, as >> well as developing a library of previously designed pieces you can >> employ later. >I agree on the experience part, but I disagree about the speed to write >code, the difference is massive; just the amount of typing alone is >radically different; optimizing assembler by hand is not trivial anymore; >if you optimize math for example, it takes a fair amount of time to produce >code faster than compilers nowdays; the result will be greater, but will >your product be? is it worth the cost? usually not at all. I work in the >video game industry, we're still using assembler a lot, but only on very >small and select pieces of the products, it is not worth doing it more; it >costs too much in time, it requires a more skilled (expensive) team, etc >and the end result is not different enough to warrant the costs It also really depends on your goals and the target. x86 assembly is relatively straightforward, so fairly easy to do OK on. IA64 is an absolute beast of convoluted rules and interlocking requirements. The "preferred" assemble IDE for IA64 is an excell spreadsheet! Also, how much of the assembly "savings" is mostly stripping out preamble/postamble code and similar modularities, which the compiler would mostly do anyway given an -O3 compiler flag? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 57263
Steve Lass wrote: > Chris, > > What version are you running? > > It sounds like you may be using an older version and possibly have some > misconceptions about how the tools work together. > > Steve Oops, I should have stated that it is 5.2i with service pack 3. Pretty up-to-date. -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.Article: 57264
Hello,
I'm currently working on dynamic partial reconfiguration with main focus on
Xilinx Virtex FPGAs.
Target Device Family: Virtex II Pro
Tool: ISE 5.2.03i
XST Design Flow
Analog to the xapp290 I made up a design consisting of 2 static + 1 dynamic
modules. Communication between them is carried out by using 4 wide + 8 wide
bus macros.
Now I encountered two problems:
1. PAR doesn't route nets that are driven by the macros TBUFs except
for one net, driven by a consistently located TBUF.
I noticed: names of nets connected to macros are unlike the
xapp290 example no combination of module name / signal name
but just the signal name. (alike the naming of Components)
-> maybe a problem with XST?
2. PAR doesn't route the clock - in spite of the insertion of
- one LOC constrained IBUFG
- "clock_signal" attribute for the clock of the top-level design
- "clock_buffer" attribute for "internal" clock signal.
Warnings:
XST:
Clock Information: No clock signals found in this design
NgdBuild:
WARNING:NgdBuild: 478 - clock net 'clk_ibuf_signal' drives no clock
pins
MAP
WARNING:DesignRules:575 - Netcheck: The clock signal clk_ibufg_signal
is not
driven by a GCLK which is not allowed for modules in partial
reconfiguration
mode.
Thank you for your attention
Any help is welcome
as well as exchange of ideas dealing with dynamic reconfiguration.
Christian
e-mail: haasecn@iis.fhg.de
Article: 57265Bob Perlman wrote: > Hi - > > The this-tool-is-no-damn-good thread pops up every few weeks. I don't > use the ECS schematic editor, so I can't comment on the its quality or > lack thereof. And I certainly don't want to get embroiled in the > schematics-vs-HDL debate which, along with cockroaches, will be the > only thing to survive a nuclear holocaust. But I will make a couple > of observations. > > First, use tools that have lots of users. Any tool developer will > spend more time fixing and maintaining popular tools than those used > only by a handful of people. And, the merits of HDLs aside, is there > any doubt that even the least popular FPGA HDL synthesis tool has at > least ten times as many users as ECS? I know, I know--this isn't > fair. But that's the way it is. Unless you're Mr. Cisco, of course. > > Second, use only those tools that add real value. There are some > Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a > useful GUI . In fact, these tools wouldn't make much sense without a > GUI. But does Project Navigator really add that much value over and > above a decent batch file that invokes tools from the command line? > Maybe the uber-GUI that ties all the tools together makes sense for > some users, but to me it's just one more thing that can break or do > inexplicable things. All I'm saying is, don't use a tool just because > it's there; the benefit should exceed the pain. > > And I agree - the Linear Tech SPICE tool is very nice. The fact that > it's free doesn't hurt, either. Thanks for your input. I think I am interested in the schematic entry for a few reasons: 1. I am a beginner at this PLD stuff, and it is the easiest way to get the chips to do something, without having to first learn HDL. 2. I am using CPLDs not FPGAs, with a heavy combinatorial emphasis, rather than state machine, heavy FF stuff. For this reason I chose Xilinx instead of Altera in the first place, as it seemed Altera didn't have as nice of an offering in the CPLD department as the Coolrunner CPLDs. Also, I want to interface as easily as I can to 5V logic systems, and the Coolrunner XPLA3 can do this directly, without added level translation glue. I just use an HCT14 to convert the 3.3V drive from the CPLD to 5V swings to send to the outside world. My application is somewhat wierd as well. We run engine research laboratories, in which there is a "patch panel" of a whole bunch of BNC connectors connected to a sampling of ANDs, ORs, etc. for gluing the various electronic subsystems of the lab together. The scientists frequently want to change their functionality, and sometimes want to add special functionality that is a bit too complex for a panel with only 20-30 gates. These "special functions" always sent me to the breadboard to prototype something with discrete logic chips that could do it, then I'd make a circuit board and install it somewhere on the rack space. I decided I wanted to build a patch panel that instead consists of a generic matric of BNCs, that interfaces to a CPLD device of moderate size. Then I can program the CPLD to be whatever arrangement of gates the scientist needs, and even more complex special functions can likely be accomodated with a few extra internal resources like a clock generator for making digital delays to replace analog one-shots, etc. 3. The schematic is the only form of circuit design that the scientists will understand, and so using schematic entry is the best way for us to communicate, and makes the circuitry self-documenting. (In the past things were laid out in pencil, then later drawn in a CAD program for the lab documentation.) Good day! -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.Article: 57266
Peter Alfke wrote: > > Not surprisingly, I agree with Austin. > SpartanXL is technically identical with XC4000XLA, but is a younger > part. It is the "last bastion" of truly low standby or idle current, > actually (typically) much lower than the guaranteed specification ( 100 > uA would be my guess). It uses one Vcc=3.3 V, and it is 5-V tolerant. > The archtecture is "ancient" by FPGA standards ( i.e. 8 years old). It > has carry and distributed RAM, but no BlockRAM, no multipliers and no > fancy clock management, but if it does your job... If this part were to be used in a new design, how long could we expect it to be available? Would you recommend this part for designs that would be in production for more than 5 years from now? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57267
> > In 20 years in this business (primarily telecom/datacom), I've never once > > had a situation where bloat was allowed. Bloat = added cost that doesn't go > > away. You burden every finished product with unecessary cost simply by poor > > design practices. A few dollars difference in parts doesn't mean much when > > you build 10. But when you built 100,000 it suddenly means a lot. I've had > > to sweat R's and C's many times, trying to remove as many as possible, and > > then try to make the remaining ones use similar values as much as > > possible -- all to try and minimize costs (cost of parts, cost of time for > > the person ordering different parts, cost of warehousing -- it all counts if > > you think about it). > > If you are in Telecom then you must have used TTC (now Acterna) test > equipment. If so, I can assure you that you have worked with bloated > software. This was done to facilitate the modularity of the hardware > (which also had to be more complex than actually required) and > subsequently was harder to maintain. Not only did they use C, but they > used C++. Clearly assembly was not needed, and the C and C++ had > advantages in time to market or why would they use it? > I'm very familiar with TTC and have used many of their products. I'm also good friends with an ex-TTC designer who spent over 10 years there. Somehow he managed to create designs that were efficient in HW and SW/FW. His products were highly successful and enjoyed some of the highest margins (from a COGS perspective) of any in the company. Guess that's why he ultimately didn't fit into the bloat mentality and went on to greener pastures. > > > Having recently done an OC48 framer design (in a couple of weeks), I could > > have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I > > aimed for a 1C3 part in the slowest speed grade. Works just fine, using > > about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not > > "expensive". Choosing to design efficiently added exactly zero time penalty > > but yielded tremendous cost savings. > > If you only used 1/3 of the LCs, then surely it would have fit using an > HDL. If you don't know how to use an HDL, then you can produce some > pretty poor code that is much larger than needed. It is another animal > to learn, but can improve your efficiency. > Just because I could have "made it fit with HDL" doesn't offer any reason to have bothered wasting my time trying. Big deal. The point wasn't to use as many resources in the part as possible. It was to use as few, leaving plenty of room for an embedded soft processor, for example, or for ATM cell delineation. > BTW, the fact that you did not even fill half of a 1C3 supports my > statement that you most likely do rather small designs. The advantages > of HDLs show when you start making larger chips. Again, you missed the point completely. My design is small, well, by design. Don't confuse "small size" with lack of complexity. Not the case at all, especially when you factor in pointer processing. If you go look at any commercially advertised OC48 core (like Altera or Paxonet, for example), they require 5 to 10 times as much logic as mine does to perform the exact same functions. ASSPs are cheaper than the FPGAs required to implement their cores. Oh, and they use HDLs. Now, what was that compelling reason to use HDL again? > > > > Again for the same reason that few designers do an entire project in > > > assembly, I won't be doing any more schematic designs. The last one I > > > did was a PITA to draw the gates needed for FSM design or worse, address > > > decoding. Data path is not bad in schematic, but the random logic is no > > > fun at all and it takes up so much space when you try to view a large > > > design. I don't mean disk space, I mean viewing space. I can view an > > > equivalent project in a text editor much more easily than a schematic > > > editor. > > > > > One startup I worked for had an embedded designer assigned to one or more > > ATM interface cards. These guys wrote in assembly only, and because of this > > were able to keep up with ATM at OC-3 rates using a very slow, primitive > > (i.e. inexpensive) micro. > > > > The fact that random gate design being "no fun at all" and "taking up a lot > > of space" suggests a few things to me. First, there are some simple rules > > for making a clean, legible schematic. Too bad schools never teach them. > > Also, I firmly believe that nearly anyone can make a functioning design > > given enough time. This doesn't make it a good design. Some designs are > > better than others, and one way to get to the "good design" stage is to get > > your fingers into the gates and learn how to work with them efficiently. > > > > I regularly test whether or not an HDL can create logic more efficiently > > than me. It can't. Not once has it implemented any type of decoding > > function better than I can. It can match me in terms of resources utilized, > > but it can't best me. By staying in the gates, I always have an instant > > grasp of how large a design is getting. I stopped one major piece of that > > OC48 design simply because it was getting too large. I knew that because I > > could see it on the page and in the floorplanner. Seeing the size forced me > > to think about other ways to implement the process. The first way worked, > > but so what? Not good enough. I needed to reduce the size to stay > > comfortably in the smaller part. > > You are missing the point. The HDL tool will not make more efficient > logic, but it can do well enough. Engineering is all about doing the > job to spec and within schedule. Trying to get your gate count lower is > a waste of time. That is the sort of stuff that kids did in school, to > make a design run even faster or make it smaller. Sure these are good > learning exercises, but in engineering the emphasis is on spec. HDLs do > a "good enough" job 99% of the time. > "good enough for gov't work", right? I'll agree that a design has to meet the desired specs. I won't agree that just any old implementation will do, especially when you add in cumulative costs of more expensive parts. I also take exception to the thought that doing it fast means sacrificing efficiency. Just not true. Not to me, or the designers I've worked with or hired. Getting gate count lower is never a waste of time as it teaches you, over time, to think efficiently right from the start. That is how you get a fast design time with efficient use of resources. Anybody can build an OC48 framer with a few million gates if they try. But how many can do it with a few thousand, and take less design time in the process? Most of the folks I've worked with can do this, but only because they learned efficient design techniques from the beginning, and honed that skill over time. > > The best HDL folks I know are ones who use it like it was a schematic. So, > > in my mind, why bother? And again, I've never had the luxury of NOT needing > > the smallest/fastest design. It's how I push 4 OC48s through a $30 part, > > saving a client millions on NOT needing to buy a bunch of expensive ASSPs > > for every board. > > > > Size does count, and I can proudly say that "mine is smaller than yours". > > ;-) > > Interesting idea of what constitutes "good" or "best". I once worked at > TRW where I learned one very valuable lesson. An optimized system is > more expensive in all areas of design. It is more expensive to design > initially since it takes more time. It is more expensive to test since > it is more complex. It is more expensive to maintain since a change is > harder to make without breaking something else. One hallmark of a good designer is that a day after finishing the design, they can think of ways to improve it. One hallmark of a great designer is knowing when something is "good enough". The best designs tend to be simple, not complex, as the best designers know how to break complicated things down into simple solutions. In general, it also yields a more efficient design in the process. Also, simpler designs are easier to maintain, as they can be understood by more people. Lastly, you learn to make these designs by learning how to "sweat the gates" and justify every piece in the design, whether it is an R, C, AND gate or FLOP. > > A smaller design is likely going to be more expensive to engineer over > the long haul. Unless you actually get into a smaller chip and save > money, you have done nothing useful. > Not in my experience. My customers have always preferred a smaller, more elegant solution as it is easier to build, test and maintain, and less expensive to boot. At some startups I worked for, that reduced cost was a strategic competitive advantage. > > > As to the picture and word analogy, I find the words to suit design > > > better. It takes a large picture and a lot of time to create it, to > > > equal those thousand words. > > > > > Some folks are visual and some folks prefer the written word. I'm obviously > > visual for circuits and have no problem using the written word, like now, > > for example. > > Seeing and creating are different. Nearly all people can understand a > good drawing more easily. That is why all my HDL designs start with > block diagrams. But turning that into a complex design in schematic is > a PITA. Once you get used to code you will find that it is much easier > to work with... or not. Your preference. > It's not. My preference. I'm like any engineer -- I will use a new tool/technique when it will benefit me or the project. Haven't seen it with HDLs. > > > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% > > of > > > > the designs he has seen are done in schematics. You can even read about > > > > graphical versions of HDL coming out. Sounds like schematics to me. > > Except > > > > that you add a layer of obfuscation in there that will make for a more > > > > bloated design. Why bother? > > > > > > I don't know where you got this, but this sounds like an exaggeration. > > > I would say he had it backwards, but I bet the schematic usage is less > > > than 20%. > > > > > I got this right from the horse's mouth. I didn't make it up. It was his > > observation of designs he's seeing. Why would he lie? He has no vested > > interest in any method his clients use. Simply the stats he sees. > > I can assure you that this is not true for design starts today. If it > were there would be a lot more postings here from people who use > schematic. There are virtually none, perhaps what, 1 a month other than > threads like this? > Not according to that FAE. He sees more design starts than either of us do. He's in a position to know. > > > > An ironic thing to notice is that if you open many of the X design > > examples > > > > included with the tools, you'll see that they are schematic based. > > > > > > > > With a schematic it is sooooo simple to identify each and every flop and > > see > > > > what it is doing in a simulation. Something isn't working in HDL? Good > > > > luck. Oh yeah, and with schematics, you never have to do all that > > modeling > > > > nonsense. While most "designers" are modeling what their circuit is > > > > supposed to do, I've already got it done, simulated, verified on the > > bench, > > > > off my plate and onto the next thing. > > > > > > If you don't feel the need to simulate, then you are clearly doing very > > > simple designs. The simulation is to make sure you are solving the > > > problem rather than just knowing what you are creating. These are two > > > different problems. > > > > > Guess you missed it when I said I simulated the designs, right before > > testing them on the bench. I never skip simulating. Again though, I prefer > > the graphical waveform version as I get to see a nice, pretty picture of > > what is happening and when. It is very simple to pull up any flop in the > > design and see it relative to anything else. Makes debugging go 10 times > > faster. And, once I'm happy with it, I can transfer the simulator results > > back into the input file so that I can compare expected to generated results > > should I make changes or add new stuff. What could be simpler? > > Then what are you talking about by "modeling"? > > If you think waveform editing is the way to go in simulation, you are > missing the best part of an HDL. Even if I had a design in schematic I > would want to simulate it in an HDL simulator. Being able to code the > environment makes life so much easier than creating waveforms. That > alone is worth using an HDL in my opinion. > Sort of like saying it's the best part of a tooth extraction. > What ever works for you. But most people have learned to use HDLs > efficiently, just as most programmers (even the best ones) have learned > to use C effectively. > Perhaps. Personally, I find that while I could type out some address decoding in an HDL quickly, I much prefer keeping my skills honed at doing gate designs just as quickly (and I'm a very fast typist). It forces me to think logically and methodically about a problem and look for the quickest, most efficient way to put the gates together. That skill pays off huge dividends when the circuit gets more complicated. A world-class athlete gets there by constant repetition and training. Same with designers who want to be world class.Article: 57268
Just took a look of a few pages of comp.arch.fpga Thread Subject: Jun 26, 2003 Xilinx Webpack bugs bugs bugs (17 articles) Jun 26, 2003 CoreGen/Ngdbuild help (2 articles) Jun 26, 2003 ERROR:iMPACT:583 (4 articles) Jun 26, 2003 Addressable Register core generator (1 article) Jun 26, 2003 Handelc, Plzzz help (1 article) P. Prasad Jun 25, 2003 Xilinx ML300 JTAG Configuration Problem (1 article) Jun 25, 2003 Xilinx XC3430A (2 articles) Jun 25, 2003 Webpack 5.2i can't synthesize (1 article) Jun 24, 2003 applying SCHMITT TRIGGER to CoolRunner-II CPLD's (2 articles) Xilinx related problems are overwhelming over Altera's. (1) Altera products are better? (2) Altera users are smarter? (3) Altera tech support ? (3) Very few people use Altera (Altera market share smaller than Xilinx) ?Article: 57269
Chris, I have had my experts look into this and they can't reproduce your problem with moving large blocks. This was a problem with earlier releases, but was fixed in 5.1i. You might want to reinstall if you're still running into this on 5.2i. Even though we do put more effort into the HDL flows, we still have engineers working on ECS. It was rewritten a couple of years ago because we plan on keeping it around for a long time. The rewrite did introduce some of the bugs you describe, but we think they are fixed in current releases. Let me know, offline, if you are still having problems. Steve Chris Carlen wrote: > Steve Lass wrote: > >> Chris, >> >> What version are you running? >> >> It sounds like you may be using an older version and possibly have >> some misconceptions about how the tools work together. >> >> Steve > > > > Oops, I should have stated that it is 5.2i with service pack 3. > Pretty up-to-date. > >Article: 57270
Rick, Well, if you go to the website, it is the last product listed for Spartan, true. If you go to the datasheet, you see it was last updated in 2002 (fairly recent). Given that we still make and support 3000 series designs (albeit with the 3100 shrink version of 3000), 5 years seems to be a pretty safe bet. The only time we obsolete products is when: the process goes away, the customers go away, or we replace it with something equivalent. The only complaint I have heard about using SpartanXL is that there are a number of more advanced lower cost products out there (that don't meet the power requirement). Austin rickman wrote: > Peter Alfke wrote: > > > > Not surprisingly, I agree with Austin. > > SpartanXL is technically identical with XC4000XLA, but is a younger > > part. It is the "last bastion" of truly low standby or idle current, > > actually (typically) much lower than the guaranteed specification ( 100 > > uA would be my guess). It uses one Vcc=3.3 V, and it is 5-V tolerant. > > The archtecture is "ancient" by FPGA standards ( i.e. 8 years old). It > > has carry and distributed RAM, but no BlockRAM, no multipliers and no > > fancy clock management, but if it does your job... > > If this part were to be used in a new design, how long could we expect > it to be available? Would you recommend this part for designs that > would be in production for more than 5 years from now? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57271
Unfair. Since Xilinx is winning 80+% of all new FPGA designs, what else would people be talking about on the website? Xilinx has a policy of "very open communications" which means just what is says. If there is a bug, we fix it. If there is a problem, we solve it. Sweeping something under the rug comes back to only kill you later! I have recently noted that Altera, Actel, and others have been using this newsgroup. That is a good thing. But do not weigh the quality of the product by the number of complaints on a newsgroup. The number of complaints results in a very healthy and very high quality product as we all read, respond, and act to fix problems, provide solutions, and give our customers the best service and value. Who do you work for, and why did you feel motivated to post this? Perhaps you need to go examine what makes up good business practices? See below for a thread by thread comment..... Austin qlyus wrote: > Just took a look of a few pages of comp.arch.fpga Thread Subject: > > Jun 26, 2003 Xilinx Webpack bugs bugs bugs (17 articles) someone who loves schematics, hates hdl, found a bug. old subject, but we care, so we respond. > > Jun 26, 2003 CoreGen/Ngdbuild help (2 articles) what is wrong with asking for help? > > Jun 26, 2003 ERROR:iMPACT:583 (4 articles) "done" doesn't go high is a pretty generic problem, we spend a lot of time on configuration issues and tools because we have to. > > Jun 26, 2003 Addressable Register core generator (1 article) > Jun 26, 2003 Handelc, Plzzz help (1 article) P. Prasad > Jun 25, 2003 Xilinx ML300 JTAG Configuration Problem (1 article) > Jun 25, 2003 Xilinx XC3430A (2 articles) Confused customer wants info on a product we don't make? > > Jun 25, 2003 Webpack 5.2i can't synthesize (1 article) > Jun 24, 2003 applying SCHMITT TRIGGER to CoolRunner-II CPLD's (2 articles) > > Xilinx related problems are overwhelming over Altera's. > > (1) Altera products are better? Market will decide. > > (2) Altera users are smarter? Market will decide. > > (3) Altera tech support ? Don't know. Don't use it much. But we did win the "top 10 best support websites" award this month. > > (3) Very few people use Altera (Altera market share smaller than Xilinx) ? Xlinx market share has increased every quarter for the last year (DataQuest-Gartner). Market will decide, not you or I.Article: 57272
On 26 Jun 2003 13:23:06 GMT, Paul Urbanus <urbpublic@hotmail.com> wrote: >I have a design that I did almost 15 years ago that fits in a 20L10 PAL. >This was written in ABEL, a PALASM like language, that was created by >Data IO (now Synario). > >I need to port this design to a 22V10, because these parts are more >readily available. This design is for a peripheral for one of the early >1980s home computers. After I port the design, I'm going to release it >into the public domain so enthusiasts of this machine can modify it if >they want. To facilitate this, I'd like to make sure that whatever tool >I use to synthesize the design can be had for free. > >I'd prefer to use ABEL, because that would require the minimum amount of >design changes. Does anyone know if there are any old versions of ABEL >(by Data IO, now Synario) that have been released into the public >domain? If not, can anyone recall what form of copy protection, if any, >was used on the old DOS versions. > >I know that Cypress has their Warp VHDL compiler for simple PALs, >including the 22V10. But, it still costs about $100. Are any of the >earlier versions available for free? > >I guess I could always use PALASM. Anywone if the latest version of this >tool supports the 22V10? And where can I find it? Atmel do a version of Wincupl, limited to their devices, but that includes 22V10. I don't know ABEL, but Cupl is a world better than PALASMArticle: 57273
Hi Christian, I'm now also working on dynamic partial reconfiguration under the ML300 platform (XC2VP7). However, I'm just starting it and I'm sorry I couldn't help you on your problem. Btw, I will be glad to share with you about dynamic partial reconfiguration later on. From application note xapp290, I see that there are quite a lot of constraints when using bus macros. So, I would prefer try the Small Bit Manipulation flow first. Have you tried that ? Cheers, tk email: tokwok@hotmail.com "Christian Haase" <haasecn@iis.fhg.de> wrote in message news:3efb2294$1@news.fhg.de... > Hello, > > I'm currently working on dynamic partial reconfiguration with main focus on > Xilinx Virtex FPGAs. > > Target Device Family: Virtex II Pro > Tool: ISE 5.2.03i > XST Design Flow > > Analog to the xapp290 I made up a design consisting of 2 static + 1 dynamic > modules. Communication between them is carried out by using 4 wide + 8 wide > bus macros. > > Now I encountered two problems: > > 1. PAR doesn't route nets that are driven by the macros TBUFs except > for one net, driven by a consistently located TBUF. > I noticed: names of nets connected to macros are unlike the > xapp290 example no combination of module name / signal name > but just the signal name. (alike the naming of Components) > -> maybe a problem with XST? > > 2. PAR doesn't route the clock - in spite of the insertion of > - one LOC constrained IBUFG > - "clock_signal" attribute for the clock of the top-level design > - "clock_buffer" attribute for "internal" clock signal. > > Warnings: > XST: > Clock Information: No clock signals found in this design > > NgdBuild: > WARNING:NgdBuild: 478 - clock net 'clk_ibuf_signal' drives no clock > pins > > MAP > WARNING:DesignRules:575 - Netcheck: The clock signal clk_ibufg_signal > is not > driven by a GCLK which is not allowed for modules in partial > reconfiguration > mode. > > > Thank you for your attention > Any help is welcome > as well as exchange of ideas dealing with dynamic reconfiguration. > > Christian > e-mail: haasecn@iis.fhg.de > > > > >Article: 57274
Chris - I don't dispute the value of schematics. I do wonder whether that value is worth the grief you're going through. Best of luck on your project. Bob Perlman Cambrian Design Works On Thu, 26 Jun 2003 09:59:44 -0700, Chris Carlen <crcarle@BOGUS.sandia.gov> wrote: >Bob Perlman wrote: >> Hi - >> >> The this-tool-is-no-damn-good thread pops up every few weeks. I don't >> use the ECS schematic editor, so I can't comment on the its quality or >> lack thereof. And I certainly don't want to get embroiled in the >> schematics-vs-HDL debate which, along with cockroaches, will be the >> only thing to survive a nuclear holocaust. But I will make a couple >> of observations. >> >> First, use tools that have lots of users. Any tool developer will >> spend more time fixing and maintaining popular tools than those used >> only by a handful of people. And, the merits of HDLs aside, is there >> any doubt that even the least popular FPGA HDL synthesis tool has at >> least ten times as many users as ECS? I know, I know--this isn't >> fair. But that's the way it is. Unless you're Mr. Cisco, of course. >> >> Second, use only those tools that add real value. There are some >> Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a >> useful GUI . In fact, these tools wouldn't make much sense without a >> GUI. But does Project Navigator really add that much value over and >> above a decent batch file that invokes tools from the command line? >> Maybe the uber-GUI that ties all the tools together makes sense for >> some users, but to me it's just one more thing that can break or do >> inexplicable things. All I'm saying is, don't use a tool just because >> it's there; the benefit should exceed the pain. >> >> And I agree - the Linear Tech SPICE tool is very nice. The fact that >> it's free doesn't hurt, either. > > >Thanks for your input. > >I think I am interested in the schematic entry for a few reasons: > >1. I am a beginner at this PLD stuff, and it is the easiest way to get >the chips to do something, without having to first learn HDL. > >2. I am using CPLDs not FPGAs, with a heavy combinatorial emphasis, >rather than state machine, heavy FF stuff. For this reason I chose >Xilinx instead of Altera in the first place, as it seemed Altera didn't >have as nice of an offering in the CPLD department as the Coolrunner CPLDs. > >Also, I want to interface as easily as I can to 5V logic systems, and >the Coolrunner XPLA3 can do this directly, without added level >translation glue. I just use an HCT14 to convert the 3.3V drive from >the CPLD to 5V swings to send to the outside world. > >My application is somewhat wierd as well. We run engine research >laboratories, in which there is a "patch panel" of a whole bunch of BNC >connectors connected to a sampling of ANDs, ORs, etc. for gluing the >various electronic subsystems of the lab together. The scientists >frequently want to change their functionality, and sometimes want to add >special functionality that is a bit too complex for a panel with only >20-30 gates. These "special functions" always sent me to the breadboard >to prototype something with discrete logic chips that could do it, then >I'd make a circuit board and install it somewhere on the rack space. > >I decided I wanted to build a patch panel that instead consists of a >generic matric of BNCs, that interfaces to a CPLD device of moderate >size. Then I can program the CPLD to be whatever arrangement of gates >the scientist needs, and even more complex special functions can likely >be accomodated with a few extra internal resources like a clock >generator for making digital delays to replace analog one-shots, etc. > >3. The schematic is the only form of circuit design that the scientists >will understand, and so using schematic entry is the best way for us to >communicate, and makes the circuitry self-documenting. (In the past >things were laid out in pencil, then later drawn in a CAD program for >the lab documentation.) > > >Good day!
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