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
I figured it out. I know that things show up all garbled here, so if anyone wants me to send it to them, just email me. Thanks, Mike Instructions for installing Xilinx Foundation 3.3.8 on Windows 2000 with a restricted student user. Mike Lowey Mike@Lowey.net U.C.Berkeley 7-9-2001 Note: These instructions are for a new install of Win2000 and Xilinx 3.1 with service pack 8 installed (3.3.8). Give the user full control of the file: C:\windows\bti.ini This file may also be called: C:\WINNT\bti.ini Also change the line: “trnfile = C:\WINDOWS” to “trnfile = C:\TEMP” Create C:\temp if it does not exist Give your user full control over C:\temp Give the user full control of the file: C:\windows\aldec.ini This file may also be called: C:\WINNT\aldec.ini Also change the line: “PROJECTS = C:\FNDTN\ACTIVE\PROJECTS\” to “PROJECTS = c:\temp” Give the user full control over: C:\WINDOWS\TEMP This file may also be called: C:\WINNT\TEMP Give the user full control in the following files: C:\windows\Mkdemsg.log C:\windows\Mkdewe.trn These files may also be called: C:\WINNT\Mkdemsg.log C:\WINNT\Mkdewe.trn Give full control to the directory: C:\Xilinx Change security permissions for the following registry keys to full control for the user: HKEY_LOCAL_MACHINE \SOFTWARE \btrieve Technologies \Aldec \Synopsis \Xilinx HKEY_CLASSES_ROOT \HKEY_CLASSES_ROOT HKEY_CURRENT_USER \Software \Classes \Aldec \Xilinx It is very likely that this configuration gives away a little bit too much control over some directories. I suspect that many of them could be read/write instead of full control. It also may not have been necessary to give full control to all of the Xilinx / Aldec / Synopsis / Btreive / classes registry entries. Some of this is adapted from Xilinx Support record number 11010 Other leads were found on Autodesk’s web site (they have similar conflicts).Article: 32876
I've been beating my head against this for several hours. I've tried LOC, RLOC, and floorplanning. It doesn't seem to be possible to place distributed dual-port RAMs. Placing a LOC on a RAM16X1D results in an error message that says you can't place the SP and DP part of a RAM in the same block. An RLOC is silently ignored. The floorplanner lets you place things wherever you want, but the mapper complains about various things. Also, mapping directives in the HDL files are incompatible with using the floorplanner: You can use one or the other, but not both. Anyone?Article: 32877
Peter, If you have 500 mA minimum, it is guaranteed to power on. If you have less than 500 mA, there are six (six!) "jump start" circuits that use the existing components (in most cases) to get you over the momentary current required. Contact your Xilinx representative and ask for these Spartan II start-up circuits (available from the Spartan Applications group). The re-characterization of Spartan II is almost complete (I know, I've said this before). We are analyzing the last lot data to revise the specificaions. Austin Peter Lang wrote: > Hi, > I am just designing a board with the Spartan2 XC2S15. > In the Data-Sheets Specs. there is a power up current of min. 500mA. > Thats quite a lot for the smallest Device. My operating current will be > about 100mA. > Do I really nead a power supply rated for 500mA at the 2.5 Volts? > Does anybody knows the reason for such a large power up current > Is this current the same for every Spartan2 Device for XC2S15 to XC2S200? > Is there a Reference Design for Power Supply? > thanks peterArticle: 32878
I have not tried it but maybe you can use a RAM64X1D instead? Its bigger but it uses the whole CLB so it might be less confusing to the tools. Steve "Don Husby" <Husby_d@yahoo.com> wrote in message news:20446075.0107101502.78e16f71@posting.google.com... > I've been beating my head against this for several hours. > I've tried LOC, RLOC, and floorplanning. It doesn't seem > to be possible to place distributed dual-port RAMs. > > Placing a LOC on a RAM16X1D results in an error message that says > you can't place the SP and DP part of a RAM in the same block. > > An RLOC is silently ignored. > > The floorplanner lets you place things wherever you want, but > the mapper complains about various things. Also, mapping > directives in the HDL files are incompatible with using the > floorplanner: You can use one or the other, but not both. > > Anyone? >Article: 32879
Kolja, If you are just changing LUTs and not wiring with the parameterization, and assuming this is for the virtex or later architecture, you could just use SRL16's in place of the LUTs to make them loadable after the FPGA is configured. I do this for my filter macros. It has the advnatage that when a customer decides to change the filter coefficients, he doesn't have to (or have me) run the design through PAR again. For DA filters, a fairly simple loader circuit can convert a naturally ordered list of coefficients into the proper partial sums for the DA LUTs. For a small overhead, you avoid alot of reconfiguration and bitstream regeneration headaches. Kolja Sulimma wrote: > 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 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: 32880
It self-sizes to the width of the signal connected to the D input. Use an unconstrained vector in the entity declarations and a constant generated usign the 'length attribute. Mine is actually structually constructed (using generate statements and the xilinx primitives), so that 1) I know I get the correct construction everytime (I've had some of the pushing on a rope syndrome in the past trying to get the tools to do the loadable downcount in one level of logic in virtex), and more importantly, It allows me to embed placement on it so that I can floorplan the counter in my source code (my code includes the RLOCs on the primitives). Actually, creating macros like this (quite a while ago now), helped get up the VHDL learning curve faster. "Keith R. Williams" wrote: > 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 > > > > > > -- -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: 32881
Austin Lesea <austin.lesea@xilinx.com> writes: > If you have less than 500 mA, there are six (six!) "jump start" circuits that > use the existing components (in most cases) to get you over the momentary > current required. Contact your Xilinx representative and ask for these > Spartan II start-up circuits (available from the Spartan Applications group). OK, I'll request that. Not to complain, but this is *exactly* the sort of information that it would be useful to be able to get from the Xilinx web site, without having to contact a Xilinx representative. Maybe you could put these circuits into an application note? Thanks! EricArticle: 32882
You will take a performance hit for doing a compare whether it is against a register or a constant. However, with the constant, there are optimizations available which will reduce the hit. Specifically, you don't need inputs to the comparator for the constant, so you get twice as many compared bits per LUT, which in turn may mean less levels of logic. You also can usually ignore some bits if the compare is against a constant and the input is a monotonic count. Note that the comparator also represents more area than the loadable counter options. True, you won't be able to change the count modulus so that it takes effect after the load but before the term count. With both the downcount to zero and the upcount from a negative number, the modulus is fixed until the next load. "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 :) > > -andy -- -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: 32883
Another thought. If you do need to change the count modulus on the fly and have it take effect immediately, you could use a DDS (aka phase accumulator). In this case, you change the increment value in a fixed count field. The msb out is at a frequency determined by the increment value. If you need a count then, you could detect the rising edge of the msb and use that to reset a counter. SO many ways to skin a cat! John_H wrote: > 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 :) > > > > -andy -- -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: 32884
The floorplanner essentially puts LOCs on it (it treats the design as flat). Have you tried putting RLOCs on by embedding the RLOCs in your source using user attributes rather than the mapping directives (you need to instantiate the RAM16x1D primitive to do that)? I have had no problem using embedded RLOCs with the floorplanner. I had had numerous problems with the synthesis vendor's RLOC directives...enough so that I stopped trying to use them some time ago. If the RLOC is being ignored, it is generally because it is being applied to a macro which does not have RLOCs on the primitives. It sounds like perhaps your synthesis tool is constructing the RAM16x1D out of other primitives rather than instantiating the RAM16x1D primitive. Try instantiating it as a black box and putting and RLOC attribute on it. Make sure the generics are not visible to the synthesis or it will screw it up. Don Husby wrote: > I've been beating my head against this for several hours. > I've tried LOC, RLOC, and floorplanning. It doesn't seem > to be possible to place distributed dual-port RAMs. > > Placing a LOC on a RAM16X1D results in an error message that says > you can't place the SP and DP part of a RAM in the same block. > > An RLOC is silently ignored. > > The floorplanner lets you place things wherever you want, but > the mapper complains about various things. Also, mapping > directives in the HDL files are incompatible with using the > floorplanner: You can use one or the other, but not both. > > Anyone? -- -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: 32885
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3B4B93DD.41D8D50@xilinx.com... > Peter, > > If you have 500 mA minimum, it is guaranteed to power on. A power supply specification this simple would be great! But what about... 1) Has the minimum VCCint rise time of 2ms and maximum rise time of 50ms gone away? [Ref. app. note XAPP189 3/20/01 page #2 and data sheet module 3 page#3.] Ensuring that VCCint doesn't rise faster than 2ms is a problem. 2) What about the requirement of VCCint not being allowed to dip in negative direction during power-on ramp? [XAPP189 & datasheet.] The datasheet has graphs that show this as a definite no-no. 3) XAPP189 also says that "When power-supply voltage falls below min. operating voltage, it should not rise immediately back to nominal operating voltage without first discharging back down to below .1V." Has this gone away? This sounds like the old crow-bar circuit that the XC2000 series required. Many years ago, we spent lots of hours trying to get these old parts to configure reliably after a brown-out. I get worried when I see this in a Xilinx app. note. > The re-characterization of Spartan II is almost complete (I know, I've said > this before). We are analyzing the last lot data to revise the > specificaions. > I commend Xilinx for documenting these power requirements so well. I hope the re-characterization has found that the parts are more immune to power-up problems. I look forward to reading the new specifications. GeraldArticle: 32886
"news_alias" <new_alias@yahoo.com> wrote in message news:<VPH27.31542$C81.2496731@bgtnsc04-news.ops.worldnet.att.net>... > 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. C has a sequential model for disambiguating dependencies, but that's really as far as it goes. That model does not imply or require serial execution and it is perfectly capable of modelling arbitrary static parallelism. (That's all you get in hardware until someone invents a way to create new gates while the system is running.) Some hardware design languages let you say how long an operation will take, but you can't do much with that ability. In particular, the correctness of the design can't depend on those numbers. (I'm ignoring the various delays used in broken verilog to trick the event queue. If your synthesized code behaves differently than your RTL until you add those delays, you're writing broken code. If the behavior of your code depends on those delays, you're writing broken code.) Delays are really just a poor-man's way of doing timing analysis. There's nothing wrong with that, but don't confuse it with any useful awareness of operation time. > To model multiple processes and the passage of time, C can be > extended. While true, that doesn't imply that such extensions are necessary or even useful for modelling hardware. With "the right extensions", you can write event-driven code in C, just like you do in Verilog. However, at that point, one might well ask why you don't simply use Verilog. If C is to be a useful hardware design language, it has to be different than Verilog. There are lots of ways to be different; I've had experience with some of them, and I've found that some work better than others. -andyArticle: 32887
> Judging from the responses here, a lot of hardware types see "C" and > assume that Handel-C is not a hardware language. You should get > familier with keywords like "par", "signal", "clock", "interface", > "chan" before assuming that Handel-C has much to do with C. > As Adrian E. Lawrence notes, it's thinly disguised Occam. > It's a lot nicer to read than Occam :-) And that's why it is very misleading to say that Handel-C is C-like. As someone else pointed out, Verilog expressions look like C expressions but still they are very different languages. Handel-C is CSP headed toward VHDL via Occam. (CSP and Occam are theoretically elegant, but there's something that kept them from being generally useful. That's a bad place to start from.) Yes, one can use various libraries to provide a different execution model in C. If that execution model is Verilog-like, you must staff your project with people who think Verilog, but are reasonably competent in C. The benefits of this approach over just using Verilog are unclear. If the execution model is something else, it's even worse. I think that to use C to design hardware, you need to restrict C's execution model, not extend it. (Yes, you need support for decent bit operations; the Frontier folks have done some nice work in this area.) Most of the restrictions are fairly obvious - they're a lot like those imposed on embedded systems. They're all consequences of the fact that hardware is static - you can't ask for more gates or wires at run-time. By restricting the execution model, "ordinary C programmers" can produce hardware, and they don't have to think differently. However, to "make timing", to make good hardware, they must do what every other hardware designer must do. They must figure out how to do the required computation with a set of operations that can be performed "fast enough", "small enough", and with not too much power. No design language can ever eliminate that requirement. For what it's worth, good software has to satisfy similar constraints, so it's fairly easy for good programmers to make the transition. (The world may be more forgiving of bad software.) So, what's the point of using C? One advantage of the restricted C model is that it eliminates heisenbugs. If there's a discrepancy between the RTL-C and the synthesized hardware, it's a synthesizer bug. (This eliminates the voodoo verilog involving #delays "to make it work", the #delays that often come back to bite you later.) It can also be transformed automatically for simulation on cheap multi-processor boxes that take the place of expensive emulation machines. (I don't know when VCS or Speedsim will be able to do the same. Remember, the behavior must not change.) I've also found that it's a more productive design language. One could argue that the C restrictions are in some sense equivalent to those of "good Verilog", which says that the possibility of bad verilog wastes time. I think that the restricted C execution model makes the design easier to understand. There's absolutely no staring at code trying to figure out what's happening, let alone "let's run it and see what happens". All of the interactions are right in front of you, so you can think about what you're trying to do instead of trying to understand what you've done or how to do it. -andyArticle: 32888
All kinds of fun going on here (comments embedded below)... cyber_spook <pjc@cyberspook.freeserve.co.uk> wrote in message news:3B4B682D.BB04BD11@cyberspook.freeserve.co.uk... > > > 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. MAX+PLUS II works well for a great majority of the designs out there. Let's not confuse the synthesis part with the rest of the tool. Altera's native VHDL synthesis has never been much more than OK (although its better than the native verilog synthesis). The rest of the tool has always been fast, relatively easy to learn, and generally quite capable. As for the synthesis, not only does Altera bundle Altera-specific versions of Synopsys' FPGA Express and Exemplar's Leonardo Spectrum with their tools subscription (as mentioned below), you can actually get these tools free from the Altera web site (along with the free version of MAX+PLUS II for the MAX and ACEX devices). -Pete- > > > > > > > > > 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 consulting >Article: 32889
Wamsi, How are you configuring the Virtex-E device? From a prom? Cable? Microprocessor/Microcontroller? What is the CCLK freq.? If its above 50MHz, you should use busy signal in SelectMap mode. Virtex-E device starts configuration after it see the sync word x"AA995566". The data following sync word has several configuration write commands, crc checks and finally some dummy words. If you haven't already checked, refer XAPP138 and Configuration problem solver on Xilinx support website. -Vikram Xilinx Applications Wamsi Mohan wrote: > Hello. > The problem I am facing is that when I try to configure the XCV600E > using selectMAP, the Done does not go high. However, INIT does not go > low either to indicate any config error. > I follow the usual steps of driving prog low and then high, waiting for > Init to go high and then clock the data[7:0]. Bitgen is compiled with > cclk option (as opposed to jtag clk or userclk). The mode pins are set > to 110 (select MAP). I have tried to abort the config cycle and read > back the status word. I read back 0xDF which Xilinx claims is correct. > > Any thoughts? > Thanks > -WamsiArticle: 32890
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. What kind of tools is your customer using ? What is the purpose of the core, to be synthesized, or only to be simulated ?Article: 32891
Good Morning,
I've this accumulator that I would want to implement on a Xilinx
XCV1000BG560-4 , the problem is that I need 165MHz and instead this
may work only at 105MHz , have you in mind any modify that I could do
to speed it up ??
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_signed.all;
entity accumulatore is
port ( freq_word : in std_logic_vector(31 downto 0);
clk, load, clear : in std_logic;
theta : inout std_logic_vector(31 downto 0)
);
end accumulatore;
architecture acc_arch of accumulatore is
signal reg_theta : std_logic_vector(31 downto 0);
begin
process(load, clear, freq_word, theta)
begin
if load='1' then
reg_theta <= freq_word;
else if clear='1' then
reg_theta <= "00000000000000000000000000000000";
else
reg_theta <= freq_word+theta;
end if;
end if;
end process;
process(clk)
begin
if clk'event and clk='1' then
theta <= reg_theta;
end if;
end process;
end acc_arch;
The Accumulator is inside a Cordic NCO and I can't utilize Core
Generator 'cause then the project will be mapped on ASIC, that I know
is more speed but I want to implement the working project also on FPGA
to simulate it accurately before of fitting on ASIC.
thank you for your help ...
Antonio D'Ottavio
Article: 32892Hello Andy, Your posts about using a C as a hardware language are interesting. Do you have any example with using C-code and storage elements? Who is doing this kind of stuff? Yours, Magnus -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 32893
Warning. I have found that RLOCs dont work for Virtex-II . While there are some trivial test cases which do work, really complex stuff like putting two flip-flops in the same slice dont work, and are ignored, with no error message. (I.e. silently ignored) Since flip flops are too hard, I wouldn't expect anything else to work either. I am using 3.3.8i I have filed a case. No result yet. Philip Freidin (I can't tell you how much I enjoy creating test cases and documenting failure modes for stuff that it is hard to believe was ever tested :-( ) On Wed, 11 Jul 2001 01:10:28 GMT, Ray Andraka <ray@andraka.com> wrote: >The floorplanner essentially puts LOCs on it (it treats the design as >flat). Have you tried putting RLOCs on by embedding the RLOCs in your >source using user attributes rather than the mapping directives (you >need to instantiate the RAM16x1D primitive to do that)? I have had no >problem using embedded RLOCs with the floorplanner. I had had numerous >problems with the synthesis vendor's RLOC directives...enough so that I >stopped trying to use them some time ago. > >If the RLOC is being ignored, it is generally because it is being >applied to a macro which does not have RLOCs on the primitives. It >sounds like perhaps your synthesis tool is constructing the RAM16x1D out >of other primitives rather than instantiating the RAM16x1D primitive. >Try instantiating it as a black box and putting and RLOC attribute on >it. Make sure the generics are not visible to the synthesis or it will >screw it up. > >Don Husby wrote: > >> I've been beating my head against this for several hours. >> I've tried LOC, RLOC, and floorplanning. It doesn't seem >> to be possible to place distributed dual-port RAMs. >> >> Placing a LOC on a RAM16X1D results in an error message that says >> you can't place the SP and DP part of a RAM in the same block. >> >> An RLOC is silently ignored. >> >> The floorplanner lets you place things wherever you want, but >> the mapper complains about various things. Also, mapping >> directives in the HDL files are incompatible with using the >> floorplanner: You can use one or the other, but not both. >> >> Anyone? Philip Freidin FliptronicsArticle: 32894
Francisco Camarero wrote: > 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. > > What kind of tools is your customer using ? > What is the purpose of the core, to be synthesized, or only to be > simulated ? The customers want to generate Xilinx FPGA configurations. Therefore they must have at least the Foundation backend tools. (Or Alliance) This is sufficient for unparametrized cores that can be distributed as EDIF netlists. What I do not know, is how to distribute synthesizable cores without distributing readable sourcecode. I do not know in advance what synthesis tools the customer is going to use, but I think I could restrict the core to certain tools. Kolja SulimmaArticle: 32895
Antonio wrote: > > Good Morning, > I've this accumulator that I would want to implement on a Xilinx > XCV1000BG560-4 , the problem is that I need 165MHz and instead this > may work only at 105MHz , have you in mind any modify that I could do > to speed it up ?? > > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use ieee.std_logic_signed.all; > > entity accumulatore is > port ( freq_word : in std_logic_vector(31 downto 0); > clk, load, clear : in std_logic; > theta : inout std_logic_vector(31 downto 0) > ); > end accumulatore; > > architecture acc_arch of accumulatore is > signal reg_theta : std_logic_vector(31 downto 0); > begin > process(load, clear, freq_word, theta) > begin > if load='1' then > reg_theta <= freq_word; > else if clear='1' then > reg_theta <= "00000000000000000000000000000000"; > else > reg_theta <= freq_word+theta; > end if; > end if; > end process; > > process(clk) > begin > if clk'event and clk='1' then > theta <= reg_theta; > end if; > end process; > end acc_arch; > > The Accumulator is inside a Cordic NCO and I can't utilize Core > Generator 'cause then the project will be mapped on ASIC, that I know > is more speed but I want to implement the working project also on FPGA > to simulate it accurately before of fitting on ASIC. > > thank you for your help ... > > Antonio D'Ottavio Is it allowed for you to pipeline it ?Article: 32896
Hello, I'm trying to implement a co-simulation framework which would allow the co-simulation of a C programm (running on a CPU) with a vhdl circuit (running on a FPGA). Specifically, I'm trying to emulate unix pipe | using two files: one is used to send data from the C program to the vhld entity, the other one is used by the vhdl entity to send data to the C program. To avoid deadlocks, i must ensure that all IO write operation are immediatly performed on the target file. This is easily handled in C with fflush(), however i didn't found any workaround for VHDL. Anyone with a clue ? Thanks StevenArticle: 32897
You can get close to 165 MHz with a 16 bit adder using the carry chain in the XCV1000-4, provided you keep the signals driving the adder inputs immediately adjacent to the adder, the logic is kept to a single level of logic (what you have there will synthesize to two levels of logic in some tools), and that they don't drive more than one or two loads. You are not going to get there with a 32 bit adder without pipelining the carry, or using two adders on alternate cycles (so that each adder is working at 82.5 MHz). If you rearrange so that the clear dominates over the load, you'd at least be able to use the sync clear input to the FF instead of the LUT for the clear function. Using the LUT for the clear requires some boolean gymnastics because the carry chain follows the lut. The logic you have right now will infer a multiplexer between the carry chain logic and the flip-flops. You are going to find it difficult to run the XCV1000-4 at 165 MHz even with 16 bit carry chains, you might consider a faster speed grade if possible (of course, if this is a Q-PRO ..ie military/space application... part, you are stuck with the 1000-4). Our FFT core, which has 20 bit carry chains and is highly optimized to the virtex architecture (we spent months tweaking it to get the last MHz out of it) is only good for 153 MHz in the virtex -4 speed grade. Antonio wrote: > Good Morning, > I've this accumulator that I would want to implement on a Xilinx > XCV1000BG560-4 , the problem is that I need 165MHz and instead this > may work only at 105MHz , have you in mind any modify that I could do > to speed it up ?? > > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use ieee.std_logic_signed.all; > > entity accumulatore is > port ( freq_word : in std_logic_vector(31 downto 0); > clk, load, clear : in std_logic; > theta : inout std_logic_vector(31 downto 0) > ); > end accumulatore; > > architecture acc_arch of accumulatore is > signal reg_theta : std_logic_vector(31 downto 0); > begin > process(load, clear, freq_word, theta) > begin > if load='1' then > reg_theta <= freq_word; > else if clear='1' then > reg_theta <= "00000000000000000000000000000000"; > else > reg_theta <= freq_word+theta; > end if; > end if; > end process; > > process(clk) > begin > if clk'event and clk='1' then > theta <= reg_theta; > end if; > end process; > end acc_arch; > > The Accumulator is inside a Cordic NCO and I can't utilize Core > Generator 'cause then the project will be mapped on ASIC, that I know > is more speed but I want to implement the working project also on FPGA > to simulate it accurately before of fitting on ASIC. > > thank you for your help ... > > Antonio D'Ottavio -- -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: 32898
All Ray said plus: If you want to work out if you stand any chance at all of getting this sort of speed, write the accumulator without the muxes (load and clear) - the fastest inferrable structure: process(clk) begin if clk'event and clk='1' then theta <= freq_word+theta; end if; end process; If this wont go at the speed you want then you'll need to find another way. Whatever you do I think you'll need to get rid of those muxes get clear from the register's direct synchronous clear and the load from 'clear' followed by first accumulate. BTW: for vtx1000e-6 (I don't have Virtex parts loaded) I got 128M for your code, 158M for the bare bones - 2speed grades up & still not quite there. FredArticle: 32899
I didn't realize this was a VirtexII. I have had near zero luck with RLOCs in virtexII so far. I'm glad someone like you is debugging it before it becomes my critical path ;-> Philip Freidin wrote: > Warning. I have found that RLOCs dont work for Virtex-II . While there are > some trivial test cases which do work, really complex stuff like putting > two flip-flops in the same slice dont work, and are ignored, with no error > message. (I.e. silently ignored) > Since flip flops are too hard, I wouldn't expect anything else to work either. > > I am using 3.3.8i > > I have filed a case. No result yet. > > Philip Freidin > > (I can't tell you how much I enjoy creating test cases and documenting > failure modes for stuff that it is hard to believe was ever tested :-( ) > > On Wed, 11 Jul 2001 01:10:28 GMT, Ray Andraka <ray@andraka.com> wrote: > >The floorplanner essentially puts LOCs on it (it treats the design as > >flat). Have you tried putting RLOCs on by embedding the RLOCs in your > >source using user attributes rather than the mapping directives (you > >need to instantiate the RAM16x1D primitive to do that)? I have had no > >problem using embedded RLOCs with the floorplanner. I had had numerous > >problems with the synthesis vendor's RLOC directives...enough so that I > >stopped trying to use them some time ago. > > > >If the RLOC is being ignored, it is generally because it is being > >applied to a macro which does not have RLOCs on the primitives. It > >sounds like perhaps your synthesis tool is constructing the RAM16x1D out > >of other primitives rather than instantiating the RAM16x1D primitive. > >Try instantiating it as a black box and putting and RLOC attribute on > >it. Make sure the generics are not visible to the synthesis or it will > >screw it up. > > > >Don Husby wrote: > > > >> I've been beating my head against this for several hours. > >> I've tried LOC, RLOC, and floorplanning. It doesn't seem > >> to be possible to place distributed dual-port RAMs. > >> > >> Placing a LOC on a RAM16X1D results in an error message that says > >> you can't place the SP and DP part of a RAM in the same block. > >> > >> An RLOC is silently ignored. > >> > >> The floorplanner lets you place things wherever you want, but > >> the mapper complains about various things. Also, mapping > >> directives in the HDL files are incompatible with using the > >> floorplanner: You can use one or the other, but not both. > >> > >> Anyone? > > Philip Freidin > Fliptronics -- -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
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