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
James Wang schrieb: > > Hi everyone, > > I'm trying to generate 200 MHz signal from 50 Mhz source using > CLKDLL. The simulation seems to work just fine. However when I try to > implement, I get the error: > > ERROR:NgdBuild:466 - input pad net 'CLK_50Mhz' has illegal > connection > ERROR:NgdBuild:466 - output pad net 'LOCK' has illegal > connection > > This was preceded by an earlier synthesis warning: > > Warning: Existing pad cell '/vers1-Optimized/CLKDLL/clkpad' is > connected to the port 'CLK_50MHz' - no pad cells inserted at this > port. (FPGA-PADMAP-1) Looks like none of your outputs are used by the design. If the are function blocks (LUTs, FFs) with unused output, the will be optimized away, which cann kill your WHOLE ciruit, leaving just the input pads and creating the warning above. > Currently I don't have any UCF file (don't know how to create one). Is Its easy, in Foundation its the file in the project directory. But be carefull, once you created a version, there is a independent *.ucf for each version. So if you make changes in the *.ucf in the main project path, copy it to the version directory (Xproject/....) > this the source of my errors? No. -- MFG FalkArticle: 32851
Lionel DORIS schrieb: > > I would like to know which is state of all I/Os before the configuration is > loaded in FPGA. They are all tristated. > Is it a bus configuration / capacitance problem ?? I dont think so, because the capacitance is also present when the FPGA is not configured. Have a look at your FPGA code (VHDL or Schematic). Check out your pinning in the pad report. Missing pin assignment (which lead to randomly assigned pins) in the UCF are not so rare :-0 -- MFG FalkArticle: 32852
Hi! I enjoy doing Open Source projects, but I now have a core that contains some trade secrets that I would like to protect. Now I wonder what is the best way to distribute a core like this. Of course I can generate a netlist macro, that the customer can instantiate. But the core needs to be parametrizable. Writing and verifying a netlist generator would be quite complicated. The development version is in VHDL and uses generics to configure the core. Can I compile this into anything that still can be configured via generics by the sourrounding VHDL but is not readable VHDL anymore? Also: Does anybody know, how I can integrate my core into the Xilinx core generator? Thanks, Kolja SulimmaArticle: 32853
If you're working in Verilog or VHDL, you can use the arithmatic directly. Result[4:0] <= {1'b0,Addme[3:0]} + (Add_Subn ? {1'b0,AddMeToo[3:0]} : -{1'b0,AddMeToo[3:0]}); Or if the core is a must, use a 5-bit adder/subtracter and tie the MSbit of each value you're adding/subtracting to logic low. - John Noddy wrote: > Hi, > > Using the Adder/Subtracter (for Spartan II), have noticed that while it > claims to be able to do 2's complement arithmatic, if I set both inputs to 4 > bits, and set my output to 4 bits (I need to truncate result to 4 bits), the > core merely outputs the 4 most significant bits and doesn't maintain two's > complement outputs. > > Does anyone know a way around this? > > AdrianArticle: 32854
> To support hardware modeling, it was necessary to extend C to allow > the programmer to model the passage of time and the execution of > statements in concurrent processes. Having actually used C to design hardware, I note that the above is both widely believed and wrong. (It's also why most of the C-based hardware design languages aren't all that useful.) Yes, physical hardware is event driven; a change in a signal can cause things to happen, and those things often happen concurrently. However, consider what "make timing" means. For almost all of us, it means "there's enough time between clocks for the hardware to react, for the relevant signals to propagate through the gates and wires". (That's true whether we're talking about activity between events for the same clock or different clocks.) That's why we tell our tools the desired clock periods and relationships. Thus, the design problem is to specify what happens between clocks. (Yes, you also have to do it within the power and area/gates budget.) One way to express activity is as events for each and every signal. Verilog is a lot like this. Many of the C-based design schemes work similarly, by allowing the designer to define events to design around. Another way is to use time-aware processes or other mechanisms. Handel-C is basically like this. A third way is to describe the activity between clocks and to use clocks to define storage. With this scheme, clocks are the only events - everything else is logic and connectivity. (Two-phase design is a mapping of this concept onto Verilog's event model.) The problem with time-aware design is that it doesn't work well in the large. People think that they know how to express parallelism, but they fail miserably when the system is large. They write heisenbugs. Such systems also force designers to say things redundantly or that shouldn't be specified by programmers. Consider a = b & c; d = e & f; In Handel-C, those statements each define storage elements, a and b, and they define a two clock sequence. What clock you ask? I don't know. Most systems that have lots of activity between clocks. Much of that activity is fairly independent. With Handel-C, multiple operations within a single clock requires more code, the "par" form, or more code for the common case. In addition, the designer has to worry about how different par forms interact. With clock-based design, as in reality, connectivity defines concurrency. You don't have to worry about evaluation order; you write what looks like boring sequential code, computing (or reading) inputs before using them in other computations, eventually leading to storage inputs, which are necessarily clocked. As a result, you just have to worry about the activity between clocks. Also, simulations really fly because there's basically no simulation overhead. The "RTL" for my designs was so fast even on a slow sparc box that that I was able to use it for application development. When I wanted a compute farm, I took some floppies to Fry's, popped them in fast PCs, hit ctrl-alt-del, and then listened to a short lecture on computers. If I'd ever run into a single simulation that took too long, another advantage of clock-based design is that it can be automatically mapped for execution on a multiprocessor, with no chance that the behavior changes at all. When these designs are mapped to hardware, all of their concurrency is exposed. If there is too much activity between clocks (either from the mapping or from your design), you won't make timing. If there is too little, maybe you're using too many clocks, or maybe you can slow them down. No matter what, the system behaves as it did before synthesis. Clock-based design does have some limitations. You can't use it for ring-oscillators (a ring of inverters with no clocked/storage elements). Some ring-like priority schemes (with clocked elements) are somewhat difficult to express as well, but they're rare enough that the extra hassle doesn't matter much. -andy ps - Yes, I had both unknowns and tri-states.Article: 32855
Niki Steenkamp wrote: > Hi, > > <completely unrelated thread deleted> > I would like to start an Altera discussion on why I get so many > "Internal Errors" from MaxPlusII as soon as I try to use more > interesting VHDL. ;-) > I wasted an afternoon trying to find such an error, when all what it > was, was a missing else clause. The other day I wasted a whole day > trying to get the "for generate" construct to work with a 2 dimensional > array. Eventually I gave up, compiled it in FPGA express and pulled in > the EDIF - no problems. ...sigh... > > I am starting to become more and more pro-3rd-party-tools. (Not that > they don't have any problems, but lets leave it at that!) > > Niki > For the last year(?) Altera has been bundling Altera-only versions of Leonardo Spectrum, ModelSim, and FPGA Express with Quartus and Max+II. While MAX+II *does* have its own Verilog and VHDL synthesis engine, Altera has apparently decided that it is better to bundle a *competitive* synthesis and sim product rather than tell their customers to either buy a *very* expensive 3rd party design seat or settle for the internal Altera synthesis tool. If you're subscribed to Altera tools support, you should have these CDs already. see http://www.altera.com/products/software/sfw-oem.html -- Bob Elkind, the e-team fpga/design consultingArticle: 32856
Andy Freeman <anamax@earthlink.net> .... > > To support hardware modeling, it was necessary to extend C to allow > > the programmer to model the passage of time and the execution of > > statements in concurrent processes. > > Having actually used C to design hardware, I note that the above is > both widely believed and wrong. (It's also why most of the C-based > hardware design languages aren't all that useful.) Are you sure? Maybe the widely held beliefs are not wrong. The programmer's model for C is for a single instruction processor and no awareness of how long it takes to process each instruction. To model multiple processes and the passage of time, C can be extended. Whether with libraries or with a new 'extended' language, something extra can be used. Compare Verilog to VHDL or Quicksim, or any other simulators (there used to be alot of them) and you'll see that they go about solving the problem of modeling hardware in a similar way. Were they all wrong?Article: 32857
I use a loadable downcounter, that way the load value is positive and term count happens when it reaches zero. I use it enough that I have a placed VHDL macro for this function. I bring the load out so that it does not necessarily have to be loaded just with the term count. The term count can be set up for registered or non-registered and active high or low through generics. The load value can be a constant or can come from a register so that you can modify it during run time. "Keith R. Williams" wrote: > In article <994760615.735193@turtle.ru.ac.za>, g9731642@campus.ru.ac.za > says... > > Yes, but are you able to change your preloaded value during run-time? It > > appears that what you are saying is that you set the preload value, and > > thats what its stuck at. I need to be able to change the preloaded value > > during runtime. > > It depends on how you deal with the loading of the (negative) number. > If you load it into a register and use the MSB to re-load the counter > the new value won't be available until the next overflow/reset. If you > load the new value into the counter when the value changes or zero is > reached, it will take effect immediately. > > ---- > Keith -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32858
Not to mention allowing placement or initial values on inferred memories. I find instantiating takes less time to get what you want, and it leaves you impervious to the whims of the synthesis tool which often changes from version to version. Phil Hays wrote: > Mike Treseler wrote: > > > Some synthesis tools allow a cleaner solution. > > I would code this RAM this as an array of vectors and > > let Leonardo generate the required BlockRAM attributes > > into the .edf file. > > Does Leonardo handle clock enables to the BlockRAM? > > Does Leonardo handle different widths on the two ports? > > Does Leonardo handle the clear register input to the BlockRAM? > > Then some of us are going to be instantiating memories... > > -- > Phil Hays -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32859
You are getting an overflow. In order to handle the full range of 4 bit inputs your output will grow to 5 bits. If you can guarantee that the output is always representable with the 4 lsbs, then you can safely discard the msb, otherwise you'll need to sign extend the inputs to 5 bits, and work with a 5 bit output. If your output has to fit in 4 bits, you can scale it by 2 by taking the 4 msbs of the output. Noddy wrote: > Hi, > > Using the Adder/Subtracter (for Spartan II), have noticed that while it > claims to be able to do 2's complement arithmatic, if I set both inputs to 4 > bits, and set my output to 4 bits (I need to truncate result to 4 bits), the > core merely outputs the 4 most significant bits and doesn't maintain two's > complement outputs. > > Does anyone know a way around this? > > Adrian -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32860
The core generator is not really set up for third parties to add cores. I've been at them to make this easier for a while. That said, Fixed (non-parameterized) cores aren't too bad for incorporating into the core generator. Basically, you need the edif netlist and a handful of files that are used for the schematic symbols, vhdl component declarations etc. Look at the 8x8 fixed multiplier in the coregenerator, and use its files as a template. Parameterized cores are not nearly as easy. They use a combination of VHDL and Java to create the netlist. If the number of variations is reasonable, the best bet is to generate a set of fixed cores :-( It would be nice if Xilinx would release a developers tool that would allow third parties to easily produce cores for coregen. To distribute as VHDL, the best suggestion I can offer is to use one of those obfuscaters to make your VHDL harder to read. Regardless of how you get there, your code has to somehow become an edif netlist to be used. If you want ot use the generics in VHDL, you're pretty much stuck with using a VHDL synthesizer to generate the edif, in which case your code still has to be legal VHDL. Kolja Sulimma wrote: > Hi! > > I enjoy doing Open Source projects, but I now have a core that contains > some trade secrets that I would like to protect. Now I wonder what is > the best way to distribute a core like this. > > Of course I can generate a netlist macro, that the customer can > instantiate. > But the core needs to be parametrizable. Writing and verifying a netlist > generator would be quite complicated. > > The development version is in VHDL and uses generics to configure the > core. Can I compile this into anything that still can be configured via > generics by the sourrounding VHDL but is not readable VHDL anymore? > > Also: Does anybody know, how I can integrate my core into the Xilinx > core generator? > > Thanks, > > Kolja Sulimma -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32861
Noddy wrote: > > Yes, but are you able to change your preloaded value during run-time? It > appears that what you are saying is that you set the preload value, and > thats what its stuck at. I need to be able to change the preloaded value > during runtime. It seems as if you want to change the number of counts on the fly, in which case the count-to-zero option won't work for you. (Like John, I also prefer count-to-zero.) You'll need some sort of load enable which lets you change terminal count value. For instance, signal count : integer range 0 to WHATEVER; signal limit : integer range 0 to WHATEVER; signal preload : integer range 0 to WHATEVER; -- other sigs are std_logic -- here's where we load the threshold limit: load_limit : process (clk, rst) is begin if rst = '1' then limit <= 0; elsif rising_edge (clk) then if loadenable = '1' then limit <= preload; end if; end if; end process load_limit; -- here's the actual counter (I assume you will have a count enable) counter : process (clk, rst) is begin if rst = '1' then count <= 0; elsif rising_edge (clk) then if countenable = '1' then if count = limit then count <= 0; else count <= count + 1; end if; end if; end if; end process counter; For some reason, I think you take a performance hit because of the compare-to-register (instead of a compare-to-constant), but quite frankly, I haven't tested this in quite a while, and I wouldn't be surprised if it didn't matter. Ray probably knows :) -andyArticle: 32862
Ray Andraka wrote > [some useful information removed] Thank you Ray. > Parameterized cores are not nearly as easy. They use a combination of VHDL > and Java to create the netlist. If the number of variations is reasonable, > the best bet is to generate a set of fixed cores :-( It would be nice if > Xilinx would release a developers tool that would allow third parties to > easily produce cores for coregen. it would indeed. > To distribute as VHDL, the best suggestion I can offer is to use one of > those obfuscaters to make your VHDL harder to read. Regardless of how you > get there, your code has to somehow become an edif netlist to be used. If > you want ot use the generics in VHDL, you're pretty much stuck with using a > VHDL synthesizer to generate the edif, in which case your code still has to > be legal VHDL. In this case I would probably have the customer send the parameters to me and I send back a netlist. But this is inconvenient for both parties. I would be nice if JBits could also operate on FPGAEditor Macros instead of device bitstreams. In this case I could for example easily replace partial products in a subcomponent. Of course I could do this in the final bitstream as well, but then the customer must invoke an additional tool every time a new bitstream is generated. (Not only when parameters change, as in the case of modifying macros) Steve, Delon: What do you think about it? Kolja SulimmaArticle: 32863
In article <3B4B4C24.CF03FFA@andraka.com>, ray@andraka.com says... > I use a loadable downcounter, that way the load value is positive and term > count happens when it reaches zero. Sure. I actually do the same. However, a down-counter isn't a lot different than an up counter loaded with a negative number. Actually, I've never synthesized the latter, so I don't know what it would look like. > I use it enough that I have a placed VHDL > macro for this function. I bring the load out so that it does not necessarily > have to be loaded just with the term count. The term count can be set up for > registered or non-registered and active high or low through generics. The > load value can be a constant or can come from a register so that you can > modify it during run time. Reusable tools are goodness. Is this a growable macro? Virtex? Actually, I'm not yet comfortable with VHDL to go this far myself. ---- Keith > > "Keith R. Williams" wrote: > > > In article <994760615.735193@turtle.ru.ac.za>, g9731642@campus.ru.ac.za > > says... > > > Yes, but are you able to change your preloaded value during run-time? It > > > appears that what you are saying is that you set the preload value, and > > > thats what its stuck at. I need to be able to change the preloaded value > > > during runtime. > > > > It depends on how you deal with the loading of the (negative) number. > > If you load it into a register and use the MSB to re-load the counter > > the new value won't be available until the next overflow/reset. If you > > load the new value into the counter when the value changes or zero is > > reached, it will take effect immediately. > > > > ---- > > Keith > > -- > -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 > > >Article: 32864
Andy, Notice that if you use the "if count = limit then" construct, your "compare to a dynamic register" will break if the counter is already beyond the new, smaller limit. If you need an instantaneous compare to the new value, adding the extra comparator logic resources is fine as long as the compare is "if count >= limit then" but in most cases the need is for a counter whose terminal count can change to a new period on the next count cycle. It's for the designer to decide. Count to zero (count up from negative preload or count down from positive preload) works fine for most designs and can eliminate the compare (if counter = 0 then) by using the sign bit. There's an extra count to include the cycle with the sign but it's just figuring out the right value to load ahead of time. Divide by 7: ...5,4,3,2,1,0,-1,5... or ...-6,-5,-4,-3,-2,-1,0,-6... where the preload is a registered item. Ray pointed out that an unregistered sign (or compare to zero) can also be used to decide the proload. There's so many flavors of vanilla it's sometimes hard to choose. I just have "my" favorite flavor of vanilla without the comparator logic. - John "Andy Peters > Noddy wrote: > > > > Yes, but are you able to change your preloaded value during run-time? It > > appears that what you are saying is that you set the preload value, and > > thats what its stuck at. I need to be able to change the preloaded value > > during runtime. > > It seems as if you want to change the number of counts on the fly, in > which case the count-to-zero option won't work for you. (Like John, I > also prefer count-to-zero.) You'll need some sort of load enable which > lets you change terminal count value. > > For instance, > > signal count : integer range 0 to WHATEVER; > signal limit : integer range 0 to WHATEVER; > signal preload : integer range 0 to WHATEVER; > -- other sigs are std_logic > > -- here's where we load the threshold limit: > load_limit : process (clk, rst) is > begin > if rst = '1' then > limit <= 0; > elsif rising_edge (clk) then > if loadenable = '1' then > limit <= preload; > end if; > end if; > end process load_limit; > > -- here's the actual counter (I assume you will have a count enable) > counter : process (clk, rst) is > begin > if rst = '1' then > count <= 0; > elsif rising_edge (clk) then > if countenable = '1' then > if count = limit then > count <= 0; > else > count <= count + 1; > end if; > end if; > end if; > end process counter; > > For some reason, I think you take a performance hit because of the > compare-to-register (instead of a compare-to-constant), but quite > frankly, I haven't tested this in quite a while, and I wouldn't be > surprised if it didn't matter. Ray probably knows :) > > -andyArticle: 32865
bob elkind wrote: > Niki Steenkamp wrote: > > > Hi, > > > > <completely unrelated thread deleted> > > > I would like to start an Altera discussion on why I get so many > > "Internal Errors" from MaxPlusII as soon as I try to use more > > interesting VHDL. ;-) > > I wasted an afternoon trying to find such an error, when all what it > > was, was a missing else clause. The other day I wasted a whole day > > trying to get the "for generate" construct to work with a 2 dimensional > > array. Eventually I gave up, compiled it in FPGA express and pulled in > > the EDIF - no problems. ...sigh... Good point - don't use MaxPlusII for this as thay never seamed to get it to work right. > > > > > I am starting to become more and more pro-3rd-party-tools. (Not that > > they don't have any problems, but lets leave it at that!) > > > > Niki > > > > For the last year(?) Altera has been bundling Altera-only versions of > Leonardo Spectrum, ModelSim, and FPGA Express with Quartus and > Max+II. While MAX+II *does* have its own Verilog and VHDL > synthesis engine, Altera has apparently decided that it is better to bundle > a *competitive* synthesis and sim product rather than tell their customers > to either buy a *very* expensive 3rd party design seat or settle for the > internal Altera synthesis tool. If you're subscribed to Altera tools support, > you should have these CDs already. > > see http://www.altera.com/products/software/sfw-oem.html > > -- Bob Elkind, the e-team fpga/design consultingArticle: 32866
Well ... Since you bypassed the Pericom part, and it works, and with the Pericom part in circuit it fails, it is modt likely that the Pericom part is doing something to your signal that is causing a problem . Except, are the signal lines that go between the CPLD and the Pericom part long, and your direct conection short? If so it might be the long traces. Otherwise, look at the rising AND falling edges of the signals at the CPLD. Maybe the edge rates suck, or there are signal integrity problems (use at least a 300 MHz scope to look at edge rates), or maybe the logic levels are not too good. Another thing would be to check the timing of the clock and data signals. Xilinx may have made a mistake in the way it bit-bangs the JTAG lines, and maybe have a timing violation (changing TDI and TCK at the same time, for instance), that you get away with on the direct connection, but fails when going through the Pericom path. (see for example http://www.fpga-faq.com/archives/30550.html#30569 ) I guess you could short out the Pericom switches one at a time and see if that localizes the problem . Philip On Tue, 10 Jul 2001 07:45:45 GMT, arast@qwest.net (Alex Rast) wrote: >In article <Vc617.4238$xY4.282582@news.uswest.net>, arast@inficom.com (Alex Rast) wrote: > >OK, I now know a little bit what's going on. > >We are using the XC95144XL in a circuit board where we have the JTAG lines to >the chip switched. The lines pass through a set of switches (Pericom PI5A100) >that are supposed to turn the JTAG lines on and off. > >Trouble is, it doesn't seem to want to work. Any time we try to pass JTAG >configuration signals through the switches, the software always errors out. >You can configure the device without incident by bypassing the switches and >connecting the JTAG signal lines from the configuration cable directly to the >XC95144. > >But I've done multiple tests with meters and scopes that verify that the >PI5A100's really are simply performing the analog switch function they're >supposed to - acting as a low resistance when on, and a very high resistance >when off. Everything - the switch voltages, the CPLD I/O, and the CPLD core, >is running at 3.3V. So why would the switches be interfering with JTAG? > >Thanks for any help. > >Alex Rast >arast@qwest.net >arast@inficom.com Philip Freidin FliptronicsArticle: 32867
bob elkind wrote: > My noble apologies and comments inserted in context -- Bob > > Rick Filipkiewicz wrote: > > > bob elkind wrote: > > > > > Rick Filipkiewicz wrote: > > > > > > > > > > I think one of the bigger reasons must be the one mentioned by Peter A. some > > > > while back. Altera employees are not allowed to post on this NG whereas > > > > Xilinx ones are automatically issued with flame-proof underwear and directed > > > > to the battlefield. > > > > > > Poppycock. Altera employees have posted on this newsgroup in the past, although > > > not anywhere near the extent of Xilinx representative postings. Check recent > > > history of the group for postings by Brian Sullivan. Its just a same they don't make thier presents felt more. Direct support like this - be it a compainy polaciy or not - shows that thier team is commited and willing to have shots fired at them. I have already made a comments before - Xilinx, Altera, etc should be giving us all the keys to making our designs better, faster, cheeper and more reliable - be it a FPGA in the next mars mission or on the motherbaord of your PC. At the end of the day we are *all* designers and should be pulling togetter. > > > > > > > > > Think of what you're saying: Actel and Altera each has employees paid > > > specifically to communicate with customers, and yet both companies prohibit > > > communication to 1000s of customers at a time via a usenet newsgroup? > > > That probably is not the case. > > > > > > > This wasn't my comment - it came from Peter A. > > Apologies -- Peter, you should be ashamed of yourself for saying such a thing! > > > > The reasons for Altera and Actel *not* having their own "Peter Alfke > > > equivalents" are (my guesses): > > > > > > 1. There is and will only be *one* Peter Alfke (had to throw that one in!). > > > > Not forgetting Austin Lesea doing good work on the DLL/PLL debate [and Shannon], > > Vikram Seth, Brian ??, Mark Ng. > > Granted. The distinction I try to make in point 2 below is that Austin, Shannon, et al > seem to be representing to this newsgroup their area of specific or general responsibility > within Xilinx, whereas Peter is Xilinx's ombudsman (I love that word!). > > > > 2. The organisational structures of Altera and Actel maintain more or less > > > distinct responsibilities between groups (e.g. marketing, sales, tech support, > > > customer service, field apps/sales, etc.). Altera or Actel) would need 3 or > > > more people (from different groups with different VPs in charge) to > > > represent the various groups in the company, a logistical (and managerial) > > > problem that makes the implementation too complicated for most companies. > > > > > > > I don't see why organisational structure has, or should have, anything to do with > > posting on a NG. > > Easy... I want to represent myself to this newsgroup, and take a dim view of > someone else doing so on my behalf without my say. Similarly, the VP of Mktg > at company B or Y (not A or X) probably takes a dim view of someone in the > tech support group presenting information to customers that is distinctly marketing > in nature. The timing, form, style, and forum all belong to the Mktg dept to > craft and plan in its own way. That planning and crafting is what Mktg gets paid to > do better than anyone in tech support. And so on... Businesses care very much > what gets "released" to customers, and how it gets "released". > > > What you seem to be saying is IMHO far too formal an approach for a NG. We're all > > grown-ups here & will allow for the fact that even an FPGA Vendor employee may have > > only part of the picture. > > Let me spin what you just said... > *MANY* of us are grownups, and *MOST* of us can handle a "raw" info feed from > vendors without sharing it with any of our colleagues who may "mishandle" the information. > After all, the institution of usenet newsgroups is one of "no-spin" raw data exchange > without the polish that makes news and info from large businesses so sterile and impersonal. > > The old days of newsgroups are (mostly) gone. What worked as a comunications > back-channel between nerds (not businesses!) can be converted to an official news > spigot for large businesses, but not without the care and "management" needed to avoid > inconsistent re-transmission, downright wrong/mis information, inadvertent pre-release > information (can you spell SEC investigation?), and corporate liability/slander risks. > > > Most times I'd rather have a description of the elephant's leg right now than wait > > for a sanctioned description of the whole animal. > > Understood. Of course, given a decent right leg description, I bet our collective minds > could come up with a pretty good picture of what we think the rest of the animal > should look like, and the fact that we all agree should be compelling evidence that > we must be pretty close to target. > > I'm not sure I've maintained the metaphors properly, but I hope we've done a good > enough job so that we can undertand each other's points of view. You make a good > case for the way things out to be (and sometimes are), and I've tried to draw an alternate > picture of the way things (sometimes) might actually be, in practice. > > I'm willing to call it a tie, and leave it at that. > > Regards, > > Bob Elkind, the e-team -- fpga/design consultingArticle: 32868
bob elkind wrote: > Steve Casselman wrote: > > > I really stopped considering Altera when they said "reconfigurable computing > > is a red herring." What happened (IMHO) is Xilinx said "we believe in the > > future of reconfigurable computing" and Altera said "we don't!" I was also > > pretty angered when one of the head people at Altera said "we make our tools > > for idiots since all engineers are idiots!" I understand your feelings - I resently was compaired to a TV engineer because I only have an HNC and not been to uni! I too would be very afended by this comment - however it shows that *some* poeple do not understand what expereance means. True an idiot can put a few lines of VHDL togetter and using thier tool make it work in cct. But these tools (and Uni for that) don't make people like the gems in this newsgroup the GOOD designers that they are! > I lost all respect Altera when > > their head of reconfigurable computing could not go to a conference (he had > > been on the program committee for years) because he was born in that city in > > which the conference was held that year. > > > > When you have been around as long as I have you get to know something about > > the companys you deal with. If I had to I'd work at Xilinx but I'd never > > work at Altera. > > > > Steve Casselman > > Interesting characterisations, Steve... > > Some of us have been around long enough (Ray Andraka, Phil Freidin, and > quite a few others) to know that both Xilinx and Altera have, on occasion, > had "BOZOs" (a technical term, not meant to insult professional clowns) > in their employ. And both outfits have some gems, as well. > > Personally, I've met both types at both companies, and I've been burnt at different > times by both companies. In one instance, my project was *sunk* by parts that > did not meet datasheet specs (and the company *knew* that, but refused to > come clean), and as a result, shortly thereafter, my career took a sharp left > (or right) turn. In short, I can personally attest to the fact that both Altera and > Xilinx are somewhat less than perfect, but are too worthy of our attention and > interest to ignore. It is a same that no firm can show true grace! Once it has a human in it - its going to have faults. > > > If I ignore or dismiss either outfit, I do myself (and my clients) a dis-service. > > Bob Elkind, the e-team: fpga/design consultingArticle: 32869
Sorry Chaps - Did not mean to start a fight. I just seam to have a way of starting things. But atleat it airs some views to the newbies that follow the group. Cyber_Spook_ManArticle: 32870
I wrote: > Hey, if people want Altera discussions on this NG, they should start some. > This is a forum of the readers, by the readers, for the readers. There > aren't any people chartered to generate new interesting content and post > it here. Kolja Sulimma <kolja@sulimma.de> writes: > I thought there are. > Or at least there are people chartered by Xilinx to answer to interesting > content posted here. > They do a great job. > The group would surely benefit from Altera and Actel doing the same. All the vendors have application engineers. Some of them participate here. AFAIK, none of them are chartered to generate new interesting content to post here. They may or may not answer questions. But if people don't post questions about a given vendor's products, no one is likely to post answers, are they?Article: 32871
Tim O'Connell wrote: > I would like to know also. I've never been able to get a constant > signal that way. If I were to code it I would use the lines Use the CONSTANT keyword. > > > SA <= "11110000"; > SB <= "00001111"; > > instead of the initialization in the signal declaration. This will > work. I don't know why the initialization doesn't work though. Correct me if I'm wrong (and they will). When this is in slicon the initialisation dose not happen - this is for simulation. You should always code your logic with constants like this. > > > "Michael Johnen" <michajo@gmx.de> wrote in message news:<9iehkl$bub$1@nets3.rz.RWTH-Aachen.DE>... > > Hi all, > > > > i try to learn vhdl and now i have problems > > i never had before: > > > > the following code.......... > > > > entity TEST13 is > > port ( > > I : in bit; > > AOUT : out bit_vector (7 downto 0)); > > > > end TEST13; > > > > architecture TEST of TEST13 is > > signal SA : bit_vector (7 downto 0) := "11110000"; > > signal SB : bit_vector (7 downto 0) := "00001111"; > > > > begin > > process (I) > > begin > > case I is > > when '1' => > > AOUT <= SA; > > when '0' => > > AOUT <= SB; > > end case; > > end process; > > > > end TEST; > > > > ..........results in following (16) errors: > > > > Error: Node ':109.IN1' missing source > > .....115.IN1... > > .....157.. > > > > What is wrong ??? My guess is.... MaxPlusII.... Its not very good at doing VHDL. I recommend that you get a copy of FPGA Express (from the altera web site) - complie your VHDL in it - export the net list (EDIF or EDF file). Make this your design entry in MaxPlusII and then complie that. A little long winded but much better, and how I do stuff at home - coz its FREE !! 80) PS: FPGA Express will not let you initialise the values for my above reson. Cyber_Spook_ManArticle: 32872
jschneider@cix.ceeowe.ewekay wrote: > hitomiandanno@cs.com (Anno) writes: > > > Does anyone know of a vendor who would sell a FPGA on a flex? > > Gosh. Money to be maid by simply sellotaping a chip to some cable. Mine come on a stiff cable called a PCB Cyber_Spook_ManArticle: 32873
Ray Andraka wrote: > ...otherwise you'll need to sign extend the inputs to 5 bits, and work with a 5 > bit output. Thanks Ray, I forget about sign extension since I've had the luxury of working only with positives for a while :-)Article: 32874
bob elkind wrote: > My noble apologies and comments inserted in context -- Bob <mucho snip of good stuff> > > I'm not sure I've maintained the metaphors properly, but I hope we've done a good > enough job so that we can undertand each other's points of view. You make a good > case for the way things out to be (and sometimes are), and I've tried to draw an alternate > picture of the way things (sometimes) might actually be, in practice. > > I'm willing to call it a tie, and leave it at that. > Draw agreed as the chess world would put it. One interesting thing you brought up - the SEC comment - of course points to a difference between your & my side of the pond. Although there are similar organisations in Europe they don't seem to inspire the same level of awe & fear.
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