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
some possible solutions/workarounds: 1. run timing analyser at 80/N MHz, to verify the multi-cycle paths; and then run timing analyser at 80 MHz for the "normal" logic paths (ignoring the spurious error reports for the multi-cycle paths). 2. insert gratuitous pipeline registers in the multi-cycle paths, to make the timing analyser happy. If done with due clevernous, this may not even affect logic cell utilisation at all (in Altera Flex devices). 3. use the "ignore paths" facilities to guide the timing analyser. You may need to declare the "result" registers of the multi-cycle paths as "LCELL"s at the top level of hierarchy, to ensure that their post-synthesis/post routing logical net names don't change from run to run. As far as I know, this is a problem common to most/all timing analysers, with the design style you've chosen, and is not particularly peculiar to MAX+II. If I'm off base on this, please correct me! It is my understanding that Quartus II will eventually supercede the MAX+II tool (with perhaps excepting the 7Kx series of CPLDs), over time. Don't delete MAX+II for at least 6 months after you *think* you're happy with Quartus II, as there will likely be weaknesses and holes in the "coverage" of any given product family as each family is first migrated from MAX+II to Quartus II. Also, be prepared to max out your PCs' memory (SDRAM) capacity, as Quartus II (like most new generations of design tools) require more memory and more compute power to deliver the same (or more) polish and sophistication as the previous design tool generation. Of course, I'm assuming that you haven't already tried these solutions and run into brick walls already, in which case I apologise for re-stating the obvioius... -- Bob Elkind, the e-team fpga/design consulting Rick Collins wrote: <quote deleted/skipped> > We are working with the 10K parts on an existing board. We are > trying to do a design with an 80 MHz clock where a portion of the > circuit uses multiple clock cycles to process signals through > combinatorial logic. It would appear that the MaxPlus II tools so not > well support this type of design timing. > > The tool problems we have found are numerous. It is a bit like being in > a maze and finding every path blocked. Our final approach is to simply > constrain the entire design to 80 MHz, and manually examine all of the > failure reports. The failures on single clock paths are fixed. The > failures on multi-cycle paths are ignored. This is not fun as the > failing paths change on each iteration of place and route. We call this > the "whack-a-mole" approach. As you fix paths, other paths then fail. > Once you have a working design, any change makes more moles pop up. > > One pleasant note is that the next release of the Quartus tool is > supposed to support the 10K series. Quartus II has much better > multi-cycle support. I don't know if they intend to support the 1K ACEX > parts with Quartus II. > > -- > > 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: 32776
On Mon, 09 Jul 2001 00:47:41 GMT, Ray Andraka <ray@andraka.com> wrote: >Synplicity is not a simulator, so I am not sure what you mean by >simulating two module netlists at once. I'm not sure what trouble you are >having. If you are creating peices of the design as separate synthesis >runs, those peices need to be instantiated as black boxes in a higher >level design. The top level will give each piece a different hierarchical >name. There can only be one top level netlist going into the xilinx >tools. Same with a simulator. I think he is trying to synthesize two (or more) modules separately and then simulate them in gate level. I can see why he is having the problem. Synplify generates gate level primitives which are instantiated in the generated module. The names of the generated primitives don't have any hierarchy attached to them so when multiple sub-blocks are synthesized, it is possible that all the generated netlists will have similarly named primitives. I have no idea how one would combine those gate-level outputs from synplify either. I guess one can find all the modules, except the one which matches the file name, and append the filename to their names. This way namespace collision can be avoided. But that wouldn't be easy. I think the script which would do it needs to understand some verilog syntax. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 32777
Hi, I have a design that uses several BlockRAMs. These blockRAMs (RAMB4_S16) should have a deafult value written in them. I am using the following code to define the INIT values of blockRAMs ... attribute INIT_00 : string; attribute INIT_01 : string; ... attribute INIT_00 of U1: label is "0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF"; attribute INIT_01 of U1: label is "0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF"; .... When I simulate I can write and read from blockRAMs normally but when I just read I do not get a default value. Instead I get a zero. I am using WebPACK 3.3 and ModelSIM 5.3 XE. The chip is Spartan2. Please help! Thank you in advance for your trouble you have taken. Best regards Jure OblakArticle: 32778
On 8 Jul 2001 23:27:46 -0700, j.oblak@iskratel.si (Jure Oblak) wrote: >Hi, > >I have a design that uses several BlockRAMs. These blockRAMs >(RAMB4_S16) should have a deafult value written in them. I am using >the following code to define the INIT values of blockRAMs > >... >attribute INIT_00 : string; >attribute INIT_01 : string; >... >attribute INIT_00 of U1: label is >"0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF"; >attribute INIT_01 of U1: label is >"0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF"; >.... > >When I simulate I can write and read from blockRAMs normally but when >I just read I do not get a default value. Instead I get a zero. I am >using WebPACK 3.3 and ModelSIM 5.3 XE. The chip is Spartan2. Please >help! >Thank you in advance for your trouble you have taken. With block rams (and many other Xilinx primitives), the block rams require the INIT generic to be set for simulation, and the attributes to be set for synthesis. (Don't ask me why, I don't write tools.) I found the best way to cope with this was to write a wrapper around the block ram which took the init value(s) as a generic, and then passed these to the block ram as generics (with those horrid translate on/off pragmas to ensure that the synthesiser doesn't see them), and also created the attributes. This way, the behaviour in simulation matches the behaviour in the downloaded FPGA. I wrote a function to convert the bit vector (of the generic) to a string (for the attributes). In an ideal world, you'd be able to get such a wrapper from the Xilinx web site. Xilinx Answer 2022 comes closest, but it's still a long way from the mark. (It only works in synthesis, not in simulation.) Regards, Allan.Article: 32779
Muzaffer Kal wrote: > On Mon, 09 Jul 2001 00:47:41 GMT, Ray Andraka <ray@andraka.com> wrote: > >Synplicity is not a simulator, so I am not sure what you mean by > >simulating two module netlists at once. I'm not sure what trouble you are > >having. If you are creating peices of the design as separate synthesis > >runs, those peices need to be instantiated as black boxes in a higher > >level design. The top level will give each piece a different hierarchical > >name. There can only be one top level netlist going into the xilinx > >tools. Same with a simulator. > > I think he is trying to synthesize two (or more) modules separately > and then simulate them in gate level. I can see why he is having the > problem. Synplify generates gate level primitives which are > instantiated in the generated module. The names of the generated > primitives don't have any hierarchy attached to them so when multiple > sub-blocks are synthesized, it is possible that all the generated > netlists will have similarly named primitives. I have no idea how one > would combine those gate-level outputs from synplify either. I guess > one can find all the modules, except the one which matches the file > name, and append the filename to their names. This way namespace > collision can be avoided. But that wouldn't be easy. I think the > script which would do it needs to understand some verilog syntax. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.com There is a trick to simulating multiple independently synth'ed modules. Basically what I do is to compile the post-synth Verilog netlists into separate libs. In the top one, just before compilation, I hack in some `uselib directives just before the instantiations of the lower level modules. This works for Verilog+ModelSim, I don't know about VHDL+ANOtherSim. Then I invoke the simulator with a lot of -L flags pointing to the compiled post-synth netlists. This has an advantage that when trying to track down a synth bug I can mix&match RTL/post-synth to speed up simulation and make it easier to trace signal names.Article: 32780
Thanks Bob, for the advice. But we already thought of these suggestions. My design takes about 30 minutes to run P&R. The timing analyzer takes about an hour. So I find that to be very painful. It is also not easy to use the "ignore paths" option. We refer to this as "cutting" the slow paths. The problem is that to identify the failing paths, we have to use the timing analyzer again. Even worse, we have to reenter the "cuts"; once for the P&R control and again for the timing analyzer (TA). They use two different sections in the ACF file for this. The TA needs the cuts in a different format which we have been using the GUI to enter. Any time we change the design, we have to redo the "cuts" in the changed sections. Finally, it did occur to us to add pipeline registers so that in effect, the entire design becomes single clock cycle. This would not use any additional LCs (at least in theory). But it would be significant work and can involve a great deal of rework since much of the slow combinatorial logic was coded in a way that we let the synthesizer deal with the optimizations. Our methode seems to be the best compromize of time and resources. I am just very surprized that the MaxPlus II software is so crude compared to the Xilinx software I am used to. I have always heard that the Altera software is so much better than the rest. bob elkind wrote: > > some possible solutions/workarounds: > > 1. run timing analyser at 80/N MHz, to verify the multi-cycle paths; > and then run timing analyser at 80 MHz for the "normal" logic paths > (ignoring the spurious error reports for the multi-cycle paths). > > 2. insert gratuitous pipeline registers in the multi-cycle paths, to make > the timing analyser happy. If done with due clevernous, this may not > even affect logic cell utilisation at all (in Altera Flex devices). > > 3. use the "ignore paths" facilities to guide the timing analyser. > > You may need to declare the "result" registers of the multi-cycle paths > as "LCELL"s at the top level of hierarchy, to ensure that their > post-synthesis/post routing logical net names don't change from run > to run. > > As far as I know, this is a problem common to most/all timing analysers, > with the design style you've chosen, and is not particularly peculiar to > MAX+II. If I'm off base on this, please correct me! > > It is my understanding that Quartus II will eventually supercede the > MAX+II tool (with perhaps excepting the 7Kx series of CPLDs), > over time. Don't delete MAX+II for at least 6 months after you *think* > you're happy with Quartus II, as there will likely be weaknesses and > holes in the "coverage" of any given product family as each family is > first migrated from MAX+II to Quartus II. Also, be prepared to max > out your PCs' memory (SDRAM) capacity, as Quartus II (like most > new generations of design tools) require more memory and more > compute power to deliver the same (or more) polish and sophistication > as the previous design tool generation. > > Of course, I'm assuming that you haven't already tried these > solutions and run into brick walls already, in which case I > apologise for re-stating the obvioius... > > -- Bob Elkind, the e-team fpga/design consulting > > Rick Collins wrote: > > <quote deleted/skipped> > > > We are working with the 10K parts on an existing board. We are > > trying to do a design with an 80 MHz clock where a portion of the > > circuit uses multiple clock cycles to process signals through > > combinatorial logic. It would appear that the MaxPlus II tools so not > > well support this type of design timing. > > > > The tool problems we have found are numerous. It is a bit like being in > > a maze and finding every path blocked. Our final approach is to simply > > constrain the entire design to 80 MHz, and manually examine all of the > > failure reports. The failures on single clock paths are fixed. The > > failures on multi-cycle paths are ignored. This is not fun as the > > failing paths change on each iteration of place and route. We call this > > the "whack-a-mole" approach. As you fix paths, other paths then fail. > > Once you have a working design, any change makes more moles pop up. > > > > One pleasant note is that the next release of the Quartus tool is > > supposed to support the 10K series. Quartus II has much better > > multi-cycle support. I don't know if they intend to support the 1K ACEX > > parts with Quartus II. > > > > -- > > > > 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 FAX -- 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: 32781
Hi, I'm using a Spartan 2 XC2S200 for the first time. Running at 32 Mhz, can anyone suggest what clock buffers would be appropriate to use? AdrianArticle: 32782
Rick, 1. 30 minutes for place and route is a *long* time for MAX+2. That would (to me) imply a 1K100 or larger device, about 75% full. What speed CPU are you running, how much memory, etc. ? Are you overdue for a motherboard upgrade? 2. Since the .ACF file is text format, it is relatively simple to add change or delete "directives". Alternative: maintain two copies of the .ACF file, with and without "ignore" directives. Don't just ignore the "failing" paths... ignore *all* the multi-cycle paths. This gets you out of the re-entering of path names repetitive exercise. 2a. Can you tweak your design structure ever so slightly so as to avoid the name changes that compel you to re-enter path names? 3. Presumably, the optimisation performed by the synthesiser should be no greater or less with pipeline registers inserted in the multi-cycle paths. Same optimisations should apply. As a note: on an Acex1K-1 (fastest speed grade), a 32-bit ADD plus 2 or more combinatorial logic levels can fit gracefully into a 12 nS path (roughly equivalent to your 85MHz clock cycle time). If re-visiting your "legacy" combinatorial logic *once* will get you out of the multi-cycle hacking that is an ongoing millstone, maybe the logic redesign is a worthwhile venture... Wouldn't it be nice to get off this treadmill you (and your successors) are on ? 4. I wouldn't necessarily characterise MAX+II as crude. For many designs, it is a turnkey solution that requires little or no tweaking to obtain suitable results on the first go. If you want to characterise this behaviour as "unsophisticated", you're entitled to do so. I'm fond of such "unsophistication"... in fact, I actively pursue design structures and styles that can be compiled and tested "with a single click". Quartus and Foundation have more sophistication (read: more tweaks), but I think that not needing such tweaks is the "sophistication" that gets designs into production quicker, and saves clients money. <... [your mileage will vary] disclaimer inserted here ...>. By the way, Quartus II has 3 different files to provide the aggregate functionality of the MAX+II .ACF file, and all three are *binary*, not ASCII text. There are workarounds, but I liked the idea of being able to browse *all* the options that might affect a design, from one file (not to mention seeing a text "diff" of two versions of the .ACF file). Interesting subject, Rick... I'm sure this will be a recurring discussion topic, in one form or another, within our online community... Good luck, Bob Elkind, the e-team fpga/design consulting Rick Collins wrote: > Thanks Bob, for the advice. But we already thought of these suggestions. > My design takes about 30 minutes to run P&R. The timing analyzer takes > about an hour. So I find that to be very painful. > > It is also not easy to use the "ignore paths" option. We refer to this > as "cutting" the slow paths. The problem is that to identify the failing > paths, we have to use the timing analyzer again. Even worse, we have to > reenter the "cuts"; once for the P&R control and again for the timing > analyzer (TA). They use two different sections in the ACF file for this. > The TA needs the cuts in a different format which we have been using the > GUI to enter. Any time we change the design, we have to redo the "cuts" > in the changed sections. > > Finally, it did occur to us to add pipeline registers so that in effect, > the entire design becomes single clock cycle. This would not use any > additional LCs (at least in theory). But it would be significant work > and can involve a great deal of rework since much of the slow > combinatorial logic was coded in a way that we let the synthesizer deal > with the optimizations. > > Our methode seems to be the best compromize of time and resources. I am > just very surprized that the MaxPlus II software is so crude compared to > the Xilinx software I am used to. I have always heard that the Altera > software is so much better than the rest. > > bob elkind wrote: > > > > some possible solutions/workarounds: > > > > 1. run timing analyser at 80/N MHz, to verify the multi-cycle paths; > > and then run timing analyser at 80 MHz for the "normal" logic paths > > (ignoring the spurious error reports for the multi-cycle paths). > > > > 2. insert gratuitous pipeline registers in the multi-cycle paths, to make > > the timing analyser happy. If done with due clevernous, this may not > > even affect logic cell utilisation at all (in Altera Flex devices). > > > > 3. use the "ignore paths" facilities to guide the timing analyser. > > > > You may need to declare the "result" registers of the multi-cycle paths > > as "LCELL"s at the top level of hierarchy, to ensure that their > > post-synthesis/post routing logical net names don't change from run > > to run. > > > > As far as I know, this is a problem common to most/all timing analysers, > > with the design style you've chosen, and is not particularly peculiar to > > MAX+II. If I'm off base on this, please correct me! > > > > It is my understanding that Quartus II will eventually supercede the > > MAX+II tool (with perhaps excepting the 7Kx series of CPLDs), > > over time. Don't delete MAX+II for at least 6 months after you *think* > > you're happy with Quartus II, as there will likely be weaknesses and > > holes in the "coverage" of any given product family as each family is > > first migrated from MAX+II to Quartus II. Also, be prepared to max > > out your PCs' memory (SDRAM) capacity, as Quartus II (like most > > new generations of design tools) require more memory and more > > compute power to deliver the same (or more) polish and sophistication > > as the previous design tool generation. > > > > Of course, I'm assuming that you haven't already tried these > > solutions and run into brick walls already, in which case I > > apologise for re-stating the obvioius... > > > > -- Bob Elkind, the e-team fpga/design consulting >Article: 32783
Hi all, Can anyone think of a way (without using a whole lot of XOR gates) to create a counter which has a threshold limit which can be updated via a port. Right now, I am just using a standard counter, then using an input bus and the output bus of the counter, XOR them all together and use result to reset the counter. Is there a more efficient way? AdrianArticle: 32784
you could do this inside an FPGA! -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel Sweden "Ivan Vernot" <ivernot@ozemail.com.au> skrev i meddelandet news:Ezj17.49677$Rr4.38763@ozemail.com.au... > > Hello FPGA Gurus, > I've been trolling the Google archives for this news group looking for a > Logic Analyzer that I may built as a kit (or buy cheaply) > > I came across reference in Oct 1996 for a company - 'ProBoard Circuits' > which sell a cheap logic analyzer. > Does anyone have any experience with this Company and have any further > contact info? > Can anyone point me in the right direction in being able to find a low cost > login analyzer for, relatively' low speed work. > > I am looking for something pretty basic - around 8 channels (min) - perhaps > 20 MHz max freq. > Any ideas? > > TIA > Ivan > > > >Article: 32785
Hi all, A similar problem has befallem me also. Using an XCS40XL, I find that I can get rid of the Multiple Drivers error message by deselecting the Create I/O Pads from Ports option, re-running Synthesis and Map, deleting the <design>.NGO file, re-selecting the Create I/O Pads, and re-running all. However, when driving a clock signal from a GPIO pin, I get an OLDMAP:56 error stating that I can not lock (using the LOC constraint in the UCF) a clock signal, which is triggering a couple of simple processes, to site type CLKIOB. Any suggestions for how to proceed? Thankyou kindly for your assistance.Article: 32786
Does anyone know the metastability characteristics for the newer Altera FPGAs like 10KE, 1K...? I know AN42, but it it quiet old they have only the metastability constants for 6k, 7k, 8k 9k and 10k. MartinArticle: 32787
Hello, the Xilinx Virtex FPGAs have block selectram and LUT selectram, what is the difference between them? I read the Xilinx doc for the Virtex family, but did not find any explanation for LUT selectram. Furthermore, where can find an example to use them with VHDL. Bye Tom!Article: 32788
"Andrew Barnes" <andrew.barnes@linn.co.uk> writes: > Hi all, > > A similar problem has befallem me also. Using an XCS40XL, I find that I can get rid of the Multiple Drivers error message by deselecting the Create I/O Pads from Ports option, re-running Synthesis and Map, deleting the <design>.NGO file, re-selecting the Create I/O Pads, and re-running all. > > However, when driving a clock signal from a GPIO pin, I get an OLDMAP:56 error stating that I can not lock (using the LOC constraint in the UCF) a clock signal, which is triggering a couple of simple processes, to site type CLKIOB. > > Any suggestions for how to proceed? Thankyou kindly for your assistance. What synthesizer are you using? The synth is mapping the signal to a global buffer, but you seem to place it in a non-global site. Tell your synth toll not to generate a global buffer. For Synplify: library IEEE, synplify; use IEEE.std_logic_1164.all; use synplify.attributes.all; entity my_design is port (o : out std_logic; i, clk_in : in std_logic); atttribute syn_noclockbuf of clk_in : signal is true; end entity; Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 32789
In article <3B49B3FA.20FD0F82@masch-bau.uni-magdeburg.de>, thomas.reinemann@masch-bau.uni-magdeburg.de says... > Hello, > > the Xilinx Virtex FPGAs have block selectram and LUT selectram, what is > the difference between them? I read the Xilinx doc for the Virtex > family, but did not find any explanation for LUT selectram. Block SelectRAM is dedicated memory with built-in "free" dual ports. LUT SelectRAM is distributed throughout the LUTS on the chip. Basically a LUT is 16 bits of memory. Stack 'em and rack 'em as needed. > Furthermore, where can find an example to use them with VHDL. It depends on your tools. Synplicity will infer distributed RAM from VHDL (not sure about BlockRAM). Look at Xilinx' APP notes and databooks. CoreGen will create all sorts of interesting things out of them too. ---- KeithArticle: 32790
Hi all, I would like to know how the Altera FLEX EPF8452A implements the registers and how difficult it would be to add some additional registers to support a high-band daughter board. I have also attached the existing interface between the micro and the altera if that might help u.... Abhimanyu Rastogi 2nd year student University of Ottawa Canada >>>>>>> editorial deletion of a uuencoded fileArticle: 32791
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: 32792
You mean like counting from 0 to 78 and resetting the counter to zero after you reach 78? Rather than resetting the counter to 0, I design my counters to reset (preload) to -78 and count up to 0. An added benefit: the LSB of the counter (the sign bit) can be used to directly drive the counter reset. Very programmable. - John Noddy wrote: > Hi all, > > Can anyone think of a way (without using a whole lot of XOR gates) to create > a counter which has a threshold limit which can be updated via a port. Right > now, I am just using a standard counter, then using an input bus and the > output bus of the counter, XOR them all together and use result to reset the > counter. Is there a more efficient way? > > AdrianArticle: 32793
bob elkind wrote: > > Rick, > > 1. 30 minutes for place and route is a *long* time for MAX+2. > That would (to me) imply a 1K100 or larger device, about 75% full. > What speed CPU are you running, how much memory, etc. ? Are > you overdue for a motherboard upgrade? I am running at 733 MHz with 128 MB memory. We are upgrading the memory, but this does not change the basic fact that the timing analysis takes twice as long as the P&R. > 2. Since the .ACF file is text format, it is relatively simple to add > change or delete "directives". Alternative: maintain two copies of > the .ACF file, with and without "ignore" directives. Don't just ignore > the "failing" paths... ignore *all* the multi-cycle paths. This gets > you out of the re-entering of path names repetitive exercise. Yes, but two copies of the file is not the issue. > 2a. Can you tweak your design structure ever so slightly so as to > avoid the name changes that compel you to re-enter path names? It is not a source file issue. Between the synthesizer and MaxPlusII, the signal names are changed (to protect the innocent?) Since I can't predict the exact names, I have to reenter the cuts so that they are expanded uniquely for each design iteration. The perferred method would be to use wildcards for the cuts. Or better yet, use the same ACF entries for both P&R and timing analysis... no, the best approach would be to produce the timing results when you run P&R. What a concept!!! > 3. Presumably, the optimisation performed by the synthesiser > should be no greater or less with pipeline registers inserted in the > multi-cycle paths. Same optimisations should apply. The point is that our code is not structured for insertion of pipeline registers. The code is functionally oriented and the logic that results is very different and frankly, unknown, since we don't really care. Inserting pipeline registers will require a great deal of work to find the points in the logic path where the delays are roughly equal. Otherwise we will never make timing. Not so easy. > As a note: on an Acex1K-1 (fastest speed grade), a 32-bit ADD > plus 2 or more combinatorial logic levels can fit gracefully into a > 12 nS path (roughly equivalent to your 85MHz clock cycle time). > If re-visiting your "legacy" combinatorial logic *once* will get you > out of the multi-cycle hacking that is an ongoing millstone, maybe > the logic redesign is a worthwhile venture... Wouldn't it be nice > to get off this treadmill you (and your successors) are on ? We are not working in a 1K part. We are using a 10K100 with 80 to 85% utilization in each of 3 different downloads. > 4. I wouldn't necessarily characterise MAX+II as crude. For many > designs, it is a turnkey solution that requires little or no tweaking to > obtain suitable results on the first go. If you want to characterise this > behaviour as "unsophisticated", you're entitled to do so. I'm fond of > such "unsophistication"... in fact, I actively pursue design structures > and styles that can be compiled and tested "with a single click". > Quartus and Foundation have more sophistication (read: more tweaks), > but I think that not needing such tweaks is the "sophistication" that > gets designs into production quicker, and saves clients money. > <... [your mileage will vary] disclaimer inserted here ...>. I am calling it "crude" because it is VERY difficult to produce an optimized design, even if working from schematic or other means of highly controlled input format. I do understand that Altera has always tried to make their devices and software work with a single button push as much as possible. But it is not good when they make it so unnecessarily difficult to optimize the design. All I really need is a detailed timing report on the failed paths when I run P&R. Xilinx has that; Lucent has that. What happened to Altera??? > By the way, Quartus II has 3 different files to provide the aggregate > functionality of the MAX+II .ACF file, and all three are *binary*, > not ASCII text. There are workarounds, but I liked the idea of > being able to browse *all* the options that might affect a design, > from one file (not to mention seeing a text "diff" of two versions of > the .ACF file). We are simultaneously implementing this same design in a 20K part using Quartus II. I was aware that there are multiple constraint files for Quartus II, but I did not know that they are binary. We version control all of our input files and it is very useful to be able to see changes. Binary files prevent this from working. But then I am told that our method with Quartus II uses TCL scripts to regenerate our constraints files from scratch each time we run. So we just source control the TCL scripts. > Interesting subject, Rick... I'm sure this will be a recurring > discussion topic, in one form or another, within our online > community... > > Good luck, > > Bob Elkind, the e-team fpga/design consulting Interesting is the right word, but I am not sure everyone understands the meaning. The Chineese have a curse, "May you live in interesting times". -- 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: 32794
Chris, I also prefer to use Synplify to enter all my constraints rather than using the UCF. Since Synplify is timing-driven, it's best to have the constraints entered pre-synthesis. However, I too have had troubles when it comes to the DLL. Synplify doesn't always recognize or pass on the fact that the actual clock frequency is different than the DLL input, even when you're using the "syn_keep" directive. In this case you might have to use the UCF for constraints. However, a colleague pointed out to me that you can use the wildcard in specifying Synplify multicycle constraints. You could constrain the whole design for 48MHz, and use the wildcard to specify which modules are 4-cycle paths. That is, instead of specifying each multicycle flop in the SDC file, like "top.module1.flop1", you can specify "top.module1.*" and Synplify will expand that in the NCF file that it passes to the router. I don't think this is in the Synplify documentation anywhere, but it works. I think you can P&R each module separately, and then use the associated placement file and guide file (for routing) for each when putting them all together, but man would that be a pain. For a 48MHz design you ought to be able to P&R with just the timing constraints. -Kevin "chris" <cjwang_1225@hotmail.com> wrote in message news:24a13eb0.0107081424.33c5c0b1@posting.google.com... > hi all. > i have a design that has two clocks on it, one at 48 mhz and one at 12 > mhz (48 mhz divide by 4). the divide down is done with the DLL on the > Virtex 300 part. currently my design passes our simulation testbench > after synthesis and place and route module by module, but when the > whole thing is integrated and then goes through the design flow, then > timing issues prevent the design from working at the specified speed. > one thing i unsuccessfully tried was to get synplicity to recognize > the 12 mhz and 48 mhz parts and optimize accordingly. i specified the > different clock signals in SCOPE, but i still get the same warnings in > the log file that some nets don't make the 48 mhz timing window (even > though the nets are in the 12 mhz section). if i had to declare all > the false or multicycle paths, it would kill me because there are so > many. i was wondering if anyone has success in getting synplicity to > recognize the different clock domains and optimize according to those > frequencies. > another thing is that i have a receive clock (RxClk) at 12 mhz which > is derived from the incoming signal, and that clock has a lot of skew > with my internal 12 mhz clock which it needs to be in phase with. is > there a way to limit this clock to clock skew? > and finally, in synplify i cannot simulate two separate module > netlists at the same time. there is overlap between the modules it > creates (ie: LUT3_2 or something like that) and it causes Verilog-XL > to choke. does anyone know how to get around this problem? i have > heard about the modular design option in synplify and am considering > it. > lastly, is it possible to place and route a design module by module? > since i can get the pieces working but not the whole, i would like to > PAR the pieces and then glue them together to make the whole. > thanks for all the previous help. sorry this message is so long. > chris >Article: 32795
It's pretty obvious that a positive second multiplicand works fine whether the first multiplicand is positive or negative. It's the second negative that's a problem. For any x and positive y x * -y = x * (16-y) for a 4 bit input x * -y = x * 16 - x * y Since what you want is - x * y you could just subtract out x*16. So a shift and add with a final subtract would get you to your goal 1110 1101 ----------- ...1111110 ...0000000 ...1111000 ...1110000 ----------- ...1100110 -..11100000 -16*(-2) ----------- ...0000110 It's not pretty but it's one way to get there. You could probably do an internet search and find a better way to implement the 4 quadrant multiplier. Enjoy. - JohnArticle: 32796
Noddy schrieb: > > Hi, > > I'm using a Spartan 2 XC2S200 for the first time. Running at 32 Mhz, can > anyone suggest what clock buffers would be appropriate to use? In general, one should use the global clock buffers (there are 4 of them), regardless of your frequncy. Even at 1 kHz, the clock skew in non-clock nets can (AND WILL!!) become too high and the design will fail. If you run out of clock nets, use longlines, wich have low skew. To do this use the following command in your *.ucf file NET my_net_name uselowskewlines; -- MFG FalkArticle: 32797
It looks like you are doing some USB 1.x stuff. I used Synopsys (& later Exemplar) tools, essentially ignoring timing in synthesis and constraining it all in the ucf. Also, only a small portion of the design I had was 48-MHz critical; you might try constraining it to 12 MHz, and just selecting the signals/paths that are 48-MHz critical and applying those constraints in the ucf. Jason chris wrote: > > hi all. > i have a design that has two clocks on it, one at 48 mhz and one at 12 > mhz (48 mhz divide by 4). the divide down is done with the DLL on the > Virtex 300 part. currently my design passes our simulation testbench > after synthesis and place and route module by module, but when the > whole thing is integrated and then goes through the design flow, then > timing issues prevent the design from working at the specified speed. > one thing i unsuccessfully tried was to get synplicity to recognize > the 12 mhz and 48 mhz parts and optimize accordingly. i specified the > different clock signals in SCOPE, but i still get the same warnings in > the log file that some nets don't make the 48 mhz timing window (even > though the nets are in the 12 mhz section). if i had to declare all > the false or multicycle paths, it would kill me because there are so > many. i was wondering if anyone has success in getting synplicity to > recognize the different clock domains and optimize according to those > frequencies. > another thing is that i have a receive clock (RxClk) at 12 mhz which > is derived from the incoming signal, and that clock has a lot of skew > with my internal 12 mhz clock which it needs to be in phase with. is > there a way to limit this clock to clock skew? > and finally, in synplify i cannot simulate two separate module > netlists at the same time. there is overlap between the modules it > creates (ie: LUT3_2 or something like that) and it causes Verilog-XL > to choke. does anyone know how to get around this problem? i have > heard about the modular design option in synplify and am considering > it. > lastly, is it possible to place and route a design module by module? > since i can get the pieces working but not the whole, i would like to > PAR the pieces and then glue them together to make the whole. > thanks for all the previous help. sorry this message is so long. > chris -- Jason T. Wright The opinions I express are my own ... unless otherwise indicated!Article: 32798
bob elkind wrote: > By the way, Quartus II has 3 different files to provide the aggregate > functionality of the MAX+II .ACF file, and all three are *binary*, > not ASCII text. This is not true. The quartus settings files are .CSF, .PSF and .ESF. They are all ASCII text. The only binary files are for the internal database. -Mike TreselerArticle: 32799
All 9500 data sheets list which Function Block and Macrocell a particular I/O pin resides in. Given that, you can judge which pins are adjacent on the die. If your IO pins fall in between two function blocks, you can usually tell if they are adjacent by looking at the pin numbers. They are adjacent as the pin numbers increase... I hope that helps.. Mark Rick Filipkiewicz wrote: > Peter Alfke wrote: > > > Yes, it works. All these output structures are almost the same. > > The issue is to what extent the current divides equally between > > the two drivers. And if they have the same basic characteristic, > > and are adjacent on the die, they track very well. > > > > Peter Alfke, Xilinx Applications > > > > Vitali wrote: > > > > > Hello, > > > > > > can I double current sink capability by tying two output pins? > > > I know it runs on FPGAs (on "senior" XC4000s). How about CPLDs? > > > > > > Thanks > > > > > > Vitali. > > How can you tell which IOs are next to each other on the die for an > XC95K part ? For Virtex devices you can get this info from a .par report > file.
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