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
Personally, I prefer to instantiate the RAMs from primitives because the inference can be quirky and sometimes changes with new releases. RAM instantiation also lets you construct exactly what you want (the structure is simple), lets you add placement constraints (the xilinx autoplace does not do very well with RAMs, Tbufs and I/O), and really doesn't take much more code than an inference does (and alot less effort with trying to get the tools to produce what you want). Rick Filipkiewicz wrote: > Metin Yerlikaya wrote: > > > Hi ! > > I'm using the Foundation Series 3.1 of Xilinx and installed it with a > > Target Device Spartan II Family. > > It seems that LogiBLOX tool does not support this family. > > If i try to add a new source to a Project , there is no LogicBLOX option but > > Coregenerator. Also when i start the logiBlox tool alone, i can not choose > > any Device > > Family and SpartanII was the only Target Family i set during installation. > > I want to instantiate a RAM Block in my design without having to write to > > behavioral Code for it as Xilinx also suggests. "Never describe RAM > > behaviorally in the HDL code, because combinatorial feedback paths will be > > inferred." > > > > How can i do this now ...i have edif file of the RAM Block i want to > > instantiate. > > Would it be enough to declare the Component and instantiate it , let the > > tool create > > a blackbox and everything will be fine during implementation phase ??? > > > > Any Reply appreciated ! > > > > Metin > > Firstly you can get SpartanII macros from Coregen by setting the the family to > Virtex [SpartanII = cheap virtex]. > > Secondly as to the Xilinx comment > > "Never describe RAM behaviorally in the HDL code, because combinatorial feedback > paths will be > inferred." > > This is true for FPGA Express [all RAMs] but Synplify and Leonardo can at infer > the small select RAMs and at least some BlockRAM structures. I don't know what > the story is for XST. -- -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: 32401
Hi,
We are using Xilinx ISE 3.1, XST compilier. The xilinx tools appear to be
telling me my design is using approximately twice as much logic as I would
expect. Consequently it does not fit the device I have targeted(XC2S50).
The design uses 1005 flip flops and 881 LUT's as shown below. I expected
the xilinx tools to use both the flip flop and LUT within a logic cell. 2
Logic cells = 1 slice. 2 slices = 1 CLB. So each slice has 2 flipflops and
2 LUT's.
So I expected the design to use approximately 1005 /2 = 500 slices. But
no, xilinx tool tells me 909 slices have been used, which is too much for
the device. Anyone got any ideas on what I am doing wrong? I have tried
optimising for area or speed at synthesis. Almost identical result. (I
also tried putting the place and route effort up to max, but again very
little effect.)
Surely the LUT and flipflop can both be used within a logic cell??
Any ideas would be much appreciated.
Design Summary:
Number of errors: 1
Number of warnings: 2
Number of Slices: 909 out of 768 118%
Number of Slices containing
unrelated logic: 35 out of 909 3%
Number of Slice Flip Flops: 1,005 out of 1,536 65%
Total Number 4 input LUTs: 881 out of 1,536 57%
Number used as LUTs: 865
Number used as a route-thru: 16
Number of bonded IOBs: 86 out of 176 48%
Number of Tbufs: 16 out of 832 1%
Number of GCLKs: 2 out of 4 50%
Number of GCLKIOBs: 2 out of 4 50%
Total equivalent gate count for design: 15,144
Additional JTAG gate count for IOBs: 4,224
Thanks Andrew
Article: 32402My first thought was that it was just the automatic placement, which tends to spread stuff out so that the slices are only half utilized, but it won't do that at the expense of forcing a larger part as is the case for yours. Something else is going on that is preventing the two flip-flops being packed into a slice. Possibilities include different clock signal names, different reset signals, or different clock enables. If your fan-out limit in the synthesizer is set low, it will duplicate some or all of these signals with different names on each. The mapper can't move instances to different nodes on an instantiated distribution tree. Try setting the fan-out limit to a higher value. Andrew Bridger wrote: > Hi, > We are using Xilinx ISE 3.1, XST compilier. The xilinx tools appear to be > telling me my design is using approximately twice as much logic as I would > expect. Consequently it does not fit the device I have targeted(XC2S50). > > The design uses 1005 flip flops and 881 LUT's as shown below. I expected > the xilinx tools to use both the flip flop and LUT within a logic cell. 2 > Logic cells = 1 slice. 2 slices = 1 CLB. So each slice has 2 flipflops and > 2 LUT's. > > So I expected the design to use approximately 1005 /2 = 500 slices. But > no, xilinx tool tells me 909 slices have been used, which is too much for > the device. Anyone got any ideas on what I am doing wrong? I have tried > optimising for area or speed at synthesis. Almost identical result. (I > also tried putting the place and route effort up to max, but again very > little effect.) > > Surely the LUT and flipflop can both be used within a logic cell?? > > Any ideas would be much appreciated. > > Design Summary: > Number of errors: 1 > Number of warnings: 2 > Number of Slices: 909 out of 768 118% > Number of Slices containing > unrelated logic: 35 out of 909 3% > Number of Slice Flip Flops: 1,005 out of 1,536 65% > Total Number 4 input LUTs: 881 out of 1,536 57% > Number used as LUTs: 865 > Number used as a route-thru: 16 > Number of bonded IOBs: 86 out of 176 48% > Number of Tbufs: 16 out of 832 1% > Number of GCLKs: 2 out of 4 50% > Number of GCLKIOBs: 2 out of 4 50% > Total equivalent gate count for design: 15,144 > Additional JTAG gate count for IOBs: 4,224 > > Thanks Andrew -- -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: 32403
Rick, Try putting the directive : /* synthesis syn_useioff=1 syn_srlstyle = "registers" */ In your module declaration. If you don't have internal feedbacks from your output signals that should do the trick for you. Note that Synplicity tends to merge duplicated registers (use syn_keep on these signals to prevent this) and convert sequential register to SRL16. Cheers, Rotem Gazit MystiCom LTD mailto:rotemg@mysticom.com http://www.mysticom.com/ Rick Collins <spamgoeshere4@yahoo.com> wrote in message news:<3B3687A7.9E58CDF8@yahoo.com>... > We are targeting a Xilinx XC4000 part and need to push some registers > into the IOBs. We like to keep our designs vendor independant, so we > prefer not to instantiate special features in the Verilog, such as IOB > FFs. > > I checked on the Xilinx web site and found that there is a directive to > designate a register to be implemented in the IOB. The directive is /* > synthesis IOB=TRUE */, and is placed in the reg declaration. This is > claimed to work with Synplify and Xilinx Alliance. When this was tried, > the FFs were still in the CLBs. > > Does anyone have experience with what we are trying to do? Should we > give up and instantiate the IOB FFs? > > -- > > 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: 32404
I have a design on a virtex part that uses the CLKDLL to generate both the
clock for the design, and the reset (by using the LOCKED signal as a
reset). In my veilog, I have the following general construct:
always @ (posedge clk or negedge reset)
begin
if (reset == 0)
begin
<all signals> <= 0;
end
else
begin
<all the rest of the logic>
end
again, the clk and reset signals are the named signals that are from the
DLL:
CLKDLL dll1 (.CLK0(clk),
.LOCKED(reset),
etc)
Now, here is the problem: On virtex parts, the standard is for the routers
to use the routing busses for the GSR (global reset/set) and NOT use the
global GSR resource. Xilinx says tha this has somrething to do with the
poor skew problem on the global resource.
But I dont want to use the local resources for this signal. After all, it
complicates my PAR (place and route) by complicating the routing. So,
Xilinx says that I can specifically instantiate the STARTUP block (which
is called STARTUP_VIRTEX for a virtex part) to dedicate the gloval and not
local resource to the reset signal. But... how do I connect it when I am
using a DLL to generate the signal??
Can I just include another instantiation:
STARTUP_VIRTEX sv1 (.GSR(reset))
to do the job?
or do I need something like:
STARTUP_VIRTEX sv1 (.GSR(~reset))
because of the polarity of the resource?
I dont find good examples of this on their website, and would appreciate
any help that anyone can offer!
Joe
yose@wam.umd.edu
Article: 32405
Rotem Gazit wrote:
> Rick,
> Try putting the directive :
> /* synthesis syn_useioff=1 syn_srlstyle = "registers" */
> In your module declaration.
> If you don't have internal feedbacks from your output signals that
> should do the trick for you.
> Note that Synplicity tends to merge duplicated registers (use syn_keep
> on these signals to prevent this) and convert sequential register to
> SRL16.
>
> Cheers,
>
Rotem & Ray A.
The problem I'm finding is not in the explicit, standalone, FFs that I want to get into IOBs or,
to put it another way, where I have to avoid feedback from an output reg. My "standard" Verlilog
state machine style is a single registered case statement with both state transitions and outputs
defined in it e.g.
always @(posedge clk)
case (state_vec)
...
some_state: begin
if (some_condition_or_other) begin
state_vec <= new_state;
iobreg <= new_value;
end
end
...
endcase
where ``iobreg'' is supposed to end up in an IOB. What the Synplify optimiser does, sometimes, is
to generate logic for ``iobreg'' that uses feedback from itself. In the two cases I'm fighting
right now the state mach is 2 levels down in the hierarchy. What Syn support told me to do is to
separate out the IOB registers into a separate always block. I really dislike that design style
since its much more awkward to document and it fails what I call the ``visibility'' test of HDL
code i.e. can you see at a glance that its right.
The second place where Synplify can implicitly break the IOB packing rules relates to the common
init condition for bidirs which are registered in both directions. Even if you have not defined a
sync reset on a FF Synplify might generate one for you! If, after logic reduction, the input
equation for an output FF can be made to look something like
!foo & bar
then Syn may put foo on the sync reset pin and bar on the D. This is the issue that I first
brought to Synplicity's attention 2 years ago. They didn't seem to understand what I was talking
about and I ended up kludging my way around it by putting fake async resets on the FFs.
In both these cases syn_useioff could easily be used to tell the optimiser/mapper not to:
(1) use feedback.
(2) generate implicit sync set/reset. Only allow ones that are explicitly defined at the HDL
source level.
Article: 32406In what document can I find a comprehensive list of all of the compiler directives? There always seems to be a directive for any particular problem that I'm having, but I never seem to know about it until I talk to someone who has had the problem before and knew (also, through osmossis, I suppose) what the right trick was... In article <86b060d0.0106252123.7784b7fd@posting.google.com>, Rotem Gazit <rotemg@mysticom.com> wrote: >Rick, >Try putting the directive : >/* synthesis syn_useioff=1 syn_srlstyle = "registers" */ >In your module declaration. >If you don't have internal feedbacks from your output signals that >should do the trick for you. >Note that Synplicity tends to merge duplicated registers (use syn_keep >on these signals to prevent this) and convert sequential register to >SRL16. > >Cheers, > >Rotem Gazit >MystiCom LTD >mailto:rotemg@mysticom.com >http://www.mysticom.com/ > > > > >Rick Collins <spamgoeshere4@yahoo.com> wrote in message news:<3B3687A7.9E58CDF8@yahoo.com>... >> We are targeting a Xilinx XC4000 part and need to push some registers >> into the IOBs. We like to keep our designs vendor independant, so we >> prefer not to instantiate special features in the Verilog, such as IOB >> FFs. >> >> I checked on the Xilinx web site and found that there is a directive to >> designate a register to be implemented in the IOB. The directive is /* >> synthesis IOB=TRUE */, and is placed in the reg declaration. This is >> claimed to work with Synplify and Xilinx Alliance. When this was tried, >> the FFs were still in the CLBs. >> >> Does anyone have experience with what we are trying to do? Should we >> give up and instantiate the IOB FFs? >>Article: 32407
Hi, Do you have an old copy of the 2500AD 68HC05 assembler and linker? It has gone out of production and is impossible to find. ThanksArticle: 32408
"Andrew Bridger" <andrew.bridger@xtra.co.nz> writes: > Hi, > We are using Xilinx ISE 3.1, XST compilier. The xilinx tools appear to be > telling me my design is using approximately twice as much logic as I would > expect. Consequently it does not fit the device I have targeted(XC2S50). Have you played with the various options to "map", e.g. -c n -detail -pr b -r? Try map -c 1 -detail and look at the result even though I'm pretty sure you will not be able to route your design after this... Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 32409
Hello out there, I have the following question regarding BUFGs in an XC4000EX: Is it possible to feed a signal coming from a "normal" pin to the global nets? Currently, P&R has problems routing a signal from outside to its destinations. I do not make any floorplanning and worse, I would like to omit this. So a colleague had the idea using the BUFGs ... If it is possible to use them from a non-dedicated clock pin, would this have any advantages? Thanks for any comments on this matter, sincerely GuidoArticle: 32410
Ray Andraka <ray@andraka.com> writes: > Synplicity, please read the above. In future versions you should consider > changing the inference of an SRL16 to infer an SRL16 plus an FD to avoid the > clock to Q penalty. I think they have. It works in 6.2.4 at least. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 32411
hi, i just want to know the advantage and disadvantage between different manufacturers of fpgas. Thks SEB -- ******************************** lerebel@fr.st http://www.lerebel.fr.st ******************************** Je suis bien dans ma peau, elle est juste à ma taille. ______________________Article: 32413
yose@wam.umd.edu (Joe Wetstein) wrote in message news:<9h9boh$7rj@rac1.wam.umd.edu>... > In what document can I find a comprehensive list of all of the compiler > directives? There always seems to be a directive for any particular > problem > that I'm having, but I never seem to know about it until I talk to > someone who has had the problem before and knew (also, through osmossis, I > suppose) what the right trick was... Check out: Synplify help -> YOUR_VENDOR Attribute and Directive Table Also: http://www.synplicity.com/literature/index.html some APPLICATION NOTES and VENDOR-SPECIFIC APPLICATION NOTES Rotem. > > > > > In article <86b060d0.0106252123.7784b7fd@posting.google.com>, > Rotem Gazit <rotemg@mysticom.com> wrote: > >Rick, > >Try putting the directive : > >/* synthesis syn_useioff=1 syn_srlstyle = "registers" */ > >In your module declaration. > >If you don't have internal feedbacks from your output signals that > >should do the trick for you. > >Note that Synplicity tends to merge duplicated registers (use syn_keep > >on these signals to prevent this) and convert sequential register to > >SRL16. > > > >Cheers, > > > >Rotem Gazit > >MystiCom LTD > >mailto:rotemg@mysticom.com > >http://www.mysticom.com/ > > > > > > > > > >Rick Collins <spamgoeshere4@yahoo.com> wrote in message news:<3B3687A7.9E58CDF8@yahoo.com>... > >> We are targeting a Xilinx XC4000 part and need to push some registers > >> into the IOBs. We like to keep our designs vendor independant, so we > >> prefer not to instantiate special features in the Verilog, such as IOB > >> FFs. > >> > >> I checked on the Xilinx web site and found that there is a directive to > >> designate a register to be implemented in the IOB. The directive is /* > >> synthesis IOB=TRUE */, and is placed in the reg declaration. This is > >> claimed to work with Synplify and Xilinx Alliance. When this was tried, > >> the FFs were still in the CLBs. > >> > >> Does anyone have experience with what we are trying to do? Should we > >> give up and instantiate the IOB FFs? > >>Article: 32414
Hi, all! State machines (SM) are made more secure with additional logic which detects an illegal state. If an illegal state occurs the SM is forced to a special state (trap state; reset state) from where it can start working correctly again. So far so good. What happens, if the additional logic is placed in LUTs of an FPGA? Aren't the LUTs vulnerable from radiation too? Is there a better protection for the configuration than for the FPGA's FFs? MichaelArticle: 32415
I am just busy doing an FPGA design for a flight safety, certified product. From what I have gathered LUT FPGA's are not recommended unless one can guarantee, by continuous test, scrubbing etc, that the device is still performing per original configuration. Not trivial do do this "on-line". Michael Boehnel wrote in message <3B386F7F.C29974E0@iti.tu-graz.ac.at>... >Hi, all! > >State machines (SM) are made more secure with additional logic which >detects an illegal state. If an illegal state occurs the SM is forced to >a special state (trap state; reset state) from where it can start >working correctly again. So far so good. > >What happens, if the additional logic is placed in LUTs of an FPGA? >Aren't the LUTs vulnerable from radiation too? >Is there a better protection for the configuration than for the FPGA's >FFs? > >Michael > >Article: 32416
There are varying degrees of protection, depending on the level of risk. The simplest, of course, is to go with no protection. In applications where the risk of upset is small or the risk of damage due to an upset is small, this is the route usually taken, as it is the cheapest. Where the risk or cost of an upset is increased there are a number of measures that can be used to detect and recover from an upset, including voting circuits (aka triple mode redundancy), periodic "scrubbing" of the configuration, periodic test vectors, monitoring configuration, and monitoring results. Some combination of these techiques as well as some not mentioned should cover you for even the most demanding environments. I am aware of the results of radiation testing on the VIrtex parts; they compare very favorably with both the SRAM elsewhere in the system, as well as microcontrollers in the system. Upsets in the design flip-flops are considerably more frequent than upsets in the configuration latches because of the design of the latches. The configuration latches are designed for more robustness at the cost of performance (you don't need high performance in the configuration latches). There are some gotchas in the Vitrex & VirtexE silicon if you intend to do continuous readback of the configuration: You cant read back any columns with LUTs configured as SRL16s or CLB RAM while the clock is running because it upsets the configuration of those cells. This limits scrubbing to columns that do not contain those cells. I do have designs going into space using the Virtex QPro parts. In these cases, we opted for putting periodic test vectors through the logic (these are signal processors) to check the health of the logic for non-critical operations, and to use triple mode redundancy for the few critical operations where a short term upset could not be tolerated. The QPro parts have an epitaxial layer that helps to reduce the radiation effects. If you are going to be working in an environment where single event upsets are a concern, you should probably be using those parts. It may be a little frustrating because in that case your biggest fastest part is equivalent to an XCV1000-4. In any event, SRAM based FPGAs are suitable for environments with elevated risk of single event upsets. As with microprocessors or memory placed in that environment, there are extra precautions that can be taken to minimize the risks. Kolja Sulimma wrote: > Continuous reconfiguration should help reduce this problem. > > Also, modern FPGAs are likely to be implemented in SOI (how about Virtex-II > ?) which is less sensible to charge insertion by alpha particles. > > At an extra nanosecond per LUT and a factor of two increase in area you can > implement every LUT twice and use the carry XOR to compare the result of the > two LUTs. You can then combine the XOR outputs with the SOP OR gates. > > A more complicated aproach takes each block of combinational logic, derives > the equation of the parity of the outputs as a function of the inputs, > performes logic optimizations and implements this carry bit in seperate LUTs. > The parity of the output is then compared to this bit. > LEON reports something 30% area overhead for this technique. > > Kolja Sulimma > > Anthony Ellis wrote: > > > I am just busy doing an FPGA design for a flight safety, certified product. > > From what I have gathered LUT FPGA's are not recommended unless one can > > guarantee, by continuous test, scrubbing etc, that the device is still > > performing per original configuration. Not trivial do do this "on-line". > > > > Michael Boehnel wrote in message <3B386F7F.C29974E0@iti.tu-graz.ac.at>... > > >Hi, all! > > > > > >State machines (SM) are made more secure with additional logic which > > >detects an illegal state. If an illegal state occurs the SM is forced to > > >a special state (trap state; reset state) from where it can start > > >working correctly again. So far so good. > > > > > >What happens, if the additional logic is placed in LUTs of an FPGA? > > >Aren't the LUTs vulnerable from radiation too? > > >Is there a better protection for the configuration than for the FPGA's > > >FFs? > > > > > >Michael > > > > > > -- -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: 32417
This is a multi-part message in MIME format. --------------6DB7B79BFAFEB37229124B80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Do you know if they have published anything regarding the ancient xc2000 series? I recently picked up a bunch of recycled xc2018's figuring I'd learn some VHDL and get some home projects on the go. Finding S/W to do P&A and to generate the configuration bitstream seems to be difficult as the current batch of free tools do not support these discontinued devices. Cheers, Michael --------------6DB7B79BFAFEB37229124B80 Content-Type: text/x-vcard; charset=us-ascii; name="michael.stevens.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Michael Stevens Content-Disposition: attachment; filename="michael.stevens.vcf" begin:vcard n:Stevens;Michael tel;work:(613) 784-6145 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:michael.stevens@alcatel.com x-mozilla-cpt:;10896 fn:Michael Stevens end:vcard --------------6DB7B79BFAFEB37229124B80--Article: 32418
Steve Casselman <sc@vcc.com> wrote: > constant just the data content of the ram is changed). We just showed this > at live at DAC where we were the only company doing partial reconfiguration. Is that partial reconfiguration using the actual features in the tools/chips though? Or did you just change the block RAM contents the regular way? Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 32419
Alan Nishioka <alann@accom.com> wrote: > My designs up to now are all pipelined by hand. I was hoping to save some time > in the future, or squeeze a little more performance out of existing designs. > Are the tools able to do this? Am I misunderstanding their capabilities? Synplify has this. I tried it a couple of times and found that the estimated clock frequency in the synthesis log file was always LOWER when retiming was enabled. I didn't experiment further. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 32420
Hi, All: I am using Xilinx System Generator to design an application in Matlab simulink evironment. I use ModelSim starter version to simulate the design. Problems occured while the vcom.do file was excecuted: I have changed the %XILINX% token in the vcom.do file into the xilinx path in my computer. errors occured as follows: # ERROR: C:/XILINX/vhdl/src/unisims is not a valid library: no info file. # ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(14): Library unisim not found. # ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(15): Unknown identifier: unisim # ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(17): VHDL Compiler exiting what is the info file? I find a info file from my matlab work directory, and copied it into the xilinx unisims path. then the following errors occured when I run modelsim: ERROR: Could not find C:/XILINX/vhdl/src/unisims.vcomponents # ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(15): cannot find expanded name: unisim.vcomponents # ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(15): Unknown field: vcomponents. # ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(17): VHDL Compiler exiting # ERROR: C:/Modeltech_xe/win32xoem/vcom failed. However, I do find a file 'unisims.vcomp' in the directory. what is the problem? thanks. JianyongArticle: 32421
Continuous reconfiguration should help reduce this problem. Also, modern FPGAs are likely to be implemented in SOI (how about Virtex-II ?) which is less sensible to charge insertion by alpha particles. At an extra nanosecond per LUT and a factor of two increase in area you can implement every LUT twice and use the carry XOR to compare the result of the two LUTs. You can then combine the XOR outputs with the SOP OR gates. A more complicated aproach takes each block of combinational logic, derives the equation of the parity of the outputs as a function of the inputs, performes logic optimizations and implements this carry bit in seperate LUTs. The parity of the output is then compared to this bit. LEON reports something 30% area overhead for this technique. Kolja Sulimma Anthony Ellis wrote: > I am just busy doing an FPGA design for a flight safety, certified product. > From what I have gathered LUT FPGA's are not recommended unless one can > guarantee, by continuous test, scrubbing etc, that the device is still > performing per original configuration. Not trivial do do this "on-line". > > Michael Boehnel wrote in message <3B386F7F.C29974E0@iti.tu-graz.ac.at>... > >Hi, all! > > > >State machines (SM) are made more secure with additional logic which > >detects an illegal state. If an illegal state occurs the SM is forced to > >a special state (trap state; reset state) from where it can start > >working correctly again. So far so good. > > > >What happens, if the additional logic is placed in LUTs of an FPGA? > >Aren't the LUTs vulnerable from radiation too? > >Is there a better protection for the configuration than for the FPGA's > >FFs? > > > >Michael > > > >Article: 32423
Phil, Here is a response from the FPGA folks regarding accuracy: "The supported FPGA families (Virtex, Virtex-E, Virtex-II, Spartan-II) have been verified against suites of characterisation designs for bels and routing resources. The accuracy, depending on the family, ranges from 80% to over 90% of the designs achieving ±10%. Some customer designs for Virtex have shown the same accuracy levels. Spartan2e could not be verified because we don't have any silicon yet." Thanks! John Hubbard, CPLD Applications Engineer John Hubbard wrote: > Phil, > > I personally have performed correlation testing for the Xilinx CoolRunner XPLA3 > CPLDs. I have a test suite containing simple designs, more complex designs, and > very complex designs. In all cases of the production released devices, >90% have > been within +/-10% accuracy with the remaining 10% within +/-20% accuracy. I speak > only for the production released Xilinx CoolRunner XPLA3 CPLDs and will forward your > question to those devoted to the Xilinx FPGAs. > > Thanks! > John > > Phil Hays wrote: > > > I've just today tried Xilinx's new power estimation tool, XPower. XPower is > > "early access" software, which I think is a new code name for beta software. > > I'm working on a design with a tight power and cooling budget, and power > > estimation is difficult. The measured difference between the spreadsheet > > estimates and the real hardware in my past designs has been 2:1, 4:1 or worse, > > which might lead to wildly over designed power supplies or worse. With large > > power budgets in past designs, this hasn't been a problem for me, however this > > project is different. While the answer I get from this tool is a lot closer to > > what I expect (and rather less than the spreadsheet estimate), and less than my > > power budget, I'm wondering how accurate this tool's results are. Any XPower > > users that have verified results against real hardware care to speak out? > > > > This tool uses a simulation pattern out of ModelSim and the placed and routed > > design, so with a realistic simulation pattern I would expect a fairly realistic > > answer. > > > > If you haven't seen this tool yet, answer 10667 has a pointer to the download > > page, or search answers for for XPower. Skip the GUI, it's gakky buggy, run in > > command line mode. > > > > -- > > Phil HaysArticle: 32424
Though I'm not familiar with the XST compiler, I've dealt with this issue in the Spartan-II architecture. Familiarization with the slice structure can help - there's a more detailed view of the slice in the Virtex data sheet than there is in the Spartan-II though they are the same architecture. Any one slice can have only one clock and one clock enable. Multiple clock domains start to "sectionalize" the design. Set/reset signals have to be the same for both flops in a slice - either both unused or both use the same signal(s). I went to great lengths to get my Synplify synthesizer to avoid FDR and FDS style primitives to avoid "losing" registers to special S/R signals. SRL and CLB selectRAM blocks use the same signal for write enable that feeds the Init (S/R) on the flops which can complicate the layout. MUXF5 and MUXF6 elements require the BX (both) and BY (F6) inputs allowing the registers only to be used for the MUX signals since lone registers need the BX or BY inputs for the "direct input" arrangement. These are some of the issues. I wouldn't be surprised, however, if the Xilinx mapper just falls short; it does in many other aspects. Your numbers *should* produce a decent design but my faith in the mapper is limited. - John Andrew Bridger wrote: > Hi, > We are using Xilinx ISE 3.1, XST compilier. The xilinx tools appear to be > telling me my design is using approximately twice as much logic as I would > expect. Consequently it does not fit the device I have targeted(XC2S50). > > The design uses 1005 flip flops and 881 LUT's as shown below. I expected > the xilinx tools to use both the flip flop and LUT within a logic cell. 2 > Logic cells = 1 slice. 2 slices = 1 CLB. So each slice has 2 flipflops and > 2 LUT's. > > So I expected the design to use approximately 1005 /2 = 500 slices. But > no, xilinx tool tells me 909 slices have been used, which is too much for > the device. Anyone got any ideas on what I am doing wrong? I have tried > optimising for area or speed at synthesis. Almost identical result. (I > also tried putting the place and route effort up to max, but again very > little effect.) > > Surely the LUT and flipflop can both be used within a logic cell?? > > Any ideas would be much appreciated. > > Design Summary: > Number of errors: 1 > Number of warnings: 2 > Number of Slices: 909 out of 768 118% > Number of Slices containing > unrelated logic: 35 out of 909 3% > Number of Slice Flip Flops: 1,005 out of 1,536 65% > Total Number 4 input LUTs: 881 out of 1,536 57% > Number used as LUTs: 865 > Number used as a route-thru: 16 > Number of bonded IOBs: 86 out of 176 48% > Number of Tbufs: 16 out of 832 1% > Number of GCLKs: 2 out of 4 50% > Number of GCLKIOBs: 2 out of 4 50% > Total equivalent gate count for design: 15,144 > Additional JTAG gate count for IOBs: 4,224 > > Thanks Andrew
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