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
Hi, My name's Leon Willett. I'm building an embedded system based on Bob Moses' miditools computer, an I wonder if you could check something out. The problem is, that 2500AD -- The company that made the 6805 assembler and linker -- was bought by Avocet. The assembler then went through so many updates and changes since Bob Moses used the software, over ten years ago, that the original assembler-specific directives are no longer respected. Basically I'm really stuck, because I have no way of finishing my project without the ancient software, which was discontinued in 1996. This is because I am using Bob's own BIOS code, and just writing my own application code -- which is the whole miditools concept. Since the only way of obtaining it is second-hand, I wrote to Bob, and asked if he would send me a copy of the assembler if he still had it around, but he doesn't. This is why I'm posting this request. Do you have an old copy of the 2500AD 68HC05 assembler and linker? Do you think you could help? Regards, Leon Willett.Article: 32376
Hi - How much timing margin do you have? Bob Perlman On Mon, 25 Jun 2001 06:48:52 -0700, "Dan Briggs" <dbriggs@opex.com> wrote: >I am having a problem with XC95108 programmable part. The part has worked in the past without problem, but with the following date codes, the part doesn't function properly. With date codes 0017, 0033, & 0037 I am recieving varying degrees of failure. With the 0017 I have one output that doesn't function and the output oscillates. With the other two I cannot generate any outputs or read inputs. The parts verify using both the Jtag in circuit programmer and a data I/O external programmer. With date code 0001 the board functions without error. All of the above stated problems occur with multiple samples of each date code, the problem is repeatable with the various date codes. I am new to the programmable device world, so any help in troubleshooting this problem would be greatly appriciated. > >Dan Briggs Opex Corporation dbriggs@opex.comArticle: 32377
If this is a speed problem ( the part being either too slow or too fast for your specific design) make the following simple tests: Cool the part down as cold as you can ( -40 degr?, using cold spray). If it works cold, you are expecting too much speed from the part. Examine your design. Heat it up to over 100 degr C. If it works then, you have designed poorly and rely on the part being slow ( race conditions, hold time problems ) Analyze your design for bad asynchronous tricks. Peter Alfke, Xilinx Applications =============================== Bob Perlman wrote: > Hi - > > How much timing margin do you have? > > Bob Perlman > > On Mon, 25 Jun 2001 06:48:52 -0700, "Dan Briggs" <dbriggs@opex.com> > wrote: > > >I am having a problem with XC95108 programmable part. The part has worked in the past > without problem, but with the following date codes, the part doesn't > function properly.Article: 32378
Peter Alfke wrote: > I have a feeling that you mix up two things: > Pipelining breaks up long combinatorial paths and inserts a flip-flop, so > that tha clock can run faster. It is my understanding that "re-timing" or "register balancing" is automatic pipelining of large combinatorial blocks. > If you do this indiscriminately, you may get into a situation where two > branches of logic must meet, but they have different numbers of pipeline > stages. You must compensate this and "balance" the number of flip-flops, so > that the branches have the same number of pipeline delays. It's obvious if > you think about it. It is difficult for a human to keep track of the timing for a bunch of different paths. It is easy for a computer, however. That is why I want the compiler to do it for me. 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? Alan Nishioka alann@accom.comArticle: 32379
I am using a Xilinx Spartan XCS40 (PQ208) FPGA running at 40MHz. I am having problems with running a nubus interface design on this FPGA with the power rails approaching 5.00v. If the power rails are dropped to 4.80v then the design works. When the voltage rail is slowly increased from 4.80v upto 5.00v parts of the design will stop working. If you reset the FPGA it sometimes starts working but will quickly stop functioning. I believe the timing in the FPGA is changing with the increased voltage on the rails but I cannot see why it is causing serious problems that I am experiencing. Has anyone come across a similar problem or knows what might be going wrong with the FPGA when the power rail is increased?Article: 32380
With earlier versions of Synplicity, /*synthesis syn_useioff=1*/ worked for me. With the latest version, I haven't been able to get it to work consistently. Some of my output FF's were turned into SRL16's because I had more than one FF in a row. The only thing I could make work was to instantiate the output and input FF's directly (ie. FD FD0 ( output, input, clock ); several hundred times) Unfortunately, this is just what you don't want to do. Alan Nishioka alann@accom.comArticle: 32381
Can anyone suggest how to insert the ADD8 component from the XilinX unified library in a VHDL design? Our target device is the XC4005XL fpga. The ADD8 component is a macro and not a primitive for XC4005XL devices. As a consequence the straightforward inclusion of the component ADD8 doesn't work. Is it necessary to include the XilinX unified library explicitely? Thank you for your attention, E. Napoli University of NapoliArticle: 32382
Rick Collins wrote: > > 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, As (the other) Rick says, don't instantiate, just tell the P+R tool to use IOFFs. For some reason, the option to use IOFFs is OFF by default. Should be ON, IMHO. -andyArticle: 32383
Gary Meakin schrieb: > > I am using a Xilinx Spartan XCS40 (PQ208) FPGA running at 40MHz. > > Has anyone come across a similar problem or knows what might be going wrong with the FPGA when the power rail is increased? Looks like an asynchronous race condition, because the device is faster with increased supply voltage. As one of the NG gurus (here P.A. ;-) said, always test your design at cold temperatures with high Vcc (fastes condition) and high temperature with low Vcc (slowes condition). When the design fails at low temperature/high Vcc, its an race condition problem, if it fails at high temperature and low Vcc, the part (design) is to slow (too much delay in the logic paths between the FFs). -- MFG FalkArticle: 32384
Ray -
Thank you VERY much. They were exactly where you said they were, and the
xilinx website showed me how to compile them in modelsim. I appreciate the
help.
But now im hitting some new snags...
Context:
For synthesis We're using Synplify 6.2.0, and foundation 3.3ip8 for
Virtex1000 and Virtex200E based Annapolis Microsystem Boards.
Heres a small snippet of my vhdl code:
-- synthesis translate_off
Library UNISIM;
use UNISIM.all;
-- synthesis translate_on
entity TEST is
-- snip (portmap)
end TEST;
architecture BEHAVIOR of TEST is
-- snip (signal declarations etc.. )
attribute syn_black_box : boolean;
component M2_1B2
port (
S0 : in std_logic;
D0 : in std_logic;
D1 : in std_logic;
O : out std_logic);
end component;
attribute syn_black_box of M2_1B2 : component is true;
begin
--snip irrelivant vhdl
testmux : M2_1B2 port map(S0 => select,
D0 => a,
D1 => b,
O => out);
-- snip MORE irrelivant vhdl
end BEHAVIOR;
When I compile this in synplify, I get a little black box in the edf file...
But when I get down to the ngdbuild phase I get:
ERROR:NgdBuild:432 - logical block
'........./textmux' with type 'M2_1B2' is
unexpanded
-------------------
Heres my real questions:
Do I need to have anything in my synplify prj file (like the vhdl for the
unisim libraries)? or will simply using the component declarations in the vhdl
like above work? Do I even need to include those compnent declarations? Im
having nightmares down the road of making many entity which use of these
unisim compnents. If I have to make the complete list of each of the
components I use in each entity, so be it... but I am hoping there is a nicer
way to do it.
I know I will need to include the (now precompiled) unisim library when doing
simulation, but im not positive that I can just ignore it completely in the
synthesis step.
Do I need to do anything at the level of the foundation tools to make them
find these components? or should they be there already?
Again... Sorry to be asking what are probably VERY basic questions, but you
have to start someplace. Thanks again
Ray Andraka wrote:
> The unisim source should be in your xilinx install directory under
> $XILINX/vhdl/src/unisims. You'll need to compile the library for your
> simulator. There are instructions available in the answers database on the
> xilinx website. If you can't find them there, I'm pretty sure you can
> download them from xilinx's website, but I'm not sure exactly where they
> are. If you can't find them there, Aldec has them on their website under
> the downloads, although you should probably check the version, it may not
> be the latest.
--
_____ _____
___ | | __ |
|___| | --| -|
|_____|__|__|
Article: 32385I tried putting the syn_hier=hard on the mapped combinatorial logic, but it still breaks it apart on me. It is taking my mapped LUT, keeping that logic but with an input ties to a constant, then producing a mux after the xorcy. Putting the syn_hier on there keeps it from optimizing off that input that is tied to a constant but does not prevent the rearrangent of the logic. Rotem Gazit wrote: > I came across this problem about a month ago. > The work around I found was to stuff the primitives in different sub > Modules (I use Verilog) and use the Directive : > /* synthesis syn_hier = "hard " */ in the sub module declaration. > Hope it helps, > Rotem. > > Ray Andraka <ray@andraka.com> wrote in message news:<3B32271D.7B7A6B17@andraka.com>... > > Synplicity 6.2 is "optimizing" an instantiated design. In particular, I > > > > have a design with instantiated Xilinx primitives including a carry > > chain. The synthesis is apparently flattening the xilinx primitives and > > > > doing its own optimization on them, which results in a multiplexer > > placed between the xorcy and the flip-flop. When I instantiate > > primitives, I don't expect to see them remapped. I didn't see this > > happening in 5.3.1. The instantiated primitives have a syn_black_box > > attribute on them. This new 'feature' makes Synplicity useless for the > > > > designs I am doing, and actually does damage for the large base I have > > already fielded. > > > > Has anyone else seen this? Any fixes? > > Rotem Gazit > MystiCom LTD > mailto:rotemg@mysticom.com > http://www.mysticom.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: 32386
In our experience It is often due to a badly shaped RAM e.g. 3 k deep is built with 3* 1k deep + logic (muxes?) but 4k deep uses narrower 4k deep blocks but no logic (It does use an extra 33% Blocks, but is much faster) Andrew Ince (P.S. sample numbers above for example only, not tested) "Kevin VAZ" <vazkevin@hotmail.com> wrote in message news:241f7389.0106202024.695ebff@posting.google.com... > Dear Friends, > > I'am having problems in understanding if my design is infering block rams or > not. > > The device used is Vertex E 600ebg432 > the EDA is Leonardo Spectrum > The design has 22 3Kbit ram instantiations > yet reports after optimisation is 66CLB > If rams are made black boxes report is 35CLB > > I would appreciate if any one can suggest a suitable solution. > Thanks, > Kevin.Article: 32388
Alan Nishioka wrote: > With earlier versions of Synplicity, /*synthesis syn_useioff=1*/ worked for me. > With the latest version, I haven't been able to get it to work consistently. Some > of my output FF's were turned into SRL16's because I had more than one FF in a row. > You could get around the SRL16 problem by putting some sort of set/reset on the FFs ? A workaround I discovered for 6.1.3 (?) which was inferring an SRL16 for my parallel-in/serial-out shift reg. > > The only thing I could make work was to instantiate the output and input FF's > directly (ie. FD FD0 ( output, input, clock ); several hundred times) > > Unfortunately, this is just what you don't want to do. > Maybe a perl script & include file would reduce the hassle ? This Xilinx packing thing has caught me out so many times right from the start of using Synplify that I'm now getting really pissed off with it. What's the point of having a synth attribute if they don't do anything with it. For Virtex the rules are very simple: output reg - no feed-back and no post FF inversion. input reg - no pre FF inversion. bi-dir registered - both of the above + common clock(easy if its a global) + common initialisation signal The common init signal in the bi-dir case doesn't even have to do the same thing to both FFs. I think the only thing you have to add for XC4K is a common clock enable. I turns out that the one Synplify breaks most often is the no-feedback rule.Article: 32389
Gary Meakin wrote: > I am using a Xilinx Spartan XCS40 (PQ208) FPGA running at 40MHz. > > I am having problems with running a nubus interface design on this FPGA with the power rails approaching 5.00v. If the power rails are dropped to 4.80v then the design works. > > When the voltage rail is slowly increased from 4.80v upto 5.00v parts of the design will stop working. If you reset the FPGA it sometimes starts working but will quickly stop functioning. I believe the timing in the FPGA is changing with the increased voltage on the rails but I cannot see why it is causing serious problems that I am experiencing. > > Has anyone come across a similar problem or knows what might be going wrong with the FPGA when the power rail is increased? Generally more volts => faster so you may have a hold time problem somewhere. Questions you need to ask yourself: 1. How many clock domains are there ? If > 1 then check your domain crossing synchronisers. This also applies to any inputs that are async to the 40MHz clock. 2. What does the timing analyser say ? 3. Does your UCF have multi-cycle delay relaxations that are not justified. What version of the s/w are you running ?Article: 32390
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 ! MetinArticle: 32391
Synopsys FPGA Compiler 2, version 3.6, released this month now supports Windows 2000 in addition to 98 and NT. Steve Duncan Sales Support Engineer Synopsys, Inc. > Petter Gustad <newsmailcomp1@gustad.com> wrote in message > news:<871yo9fwkv.fsf@firewall.home.gustad.com>... > Duane Clark <dclark@akamail.com> writes: > > > Synopsis - Design Compiler and other tools. It is not clear whether they > > are actually available yet, and I don't see prices. > > http://www.synopsis.com/news/announce/press2000/linux_pr.html > > I use Synopsys Design Compiler, PrimeTime, and VCS under Linux. The > latter has been available for several years. > > > Cadence - NCSim and other tools - US$5K (I think, the Cadence web site > > is rather hard to use) > > http://www.cadence.com/company/pr/04_17_00linux.html > > I use Cadence Verilog XL under Linux - works great. > > I have simulations running for weeks. I can't use Windows since it has > to be booted all the time. A reboot is an accepted part of the > installation procedure on Windows. Install a small utility program, > and you have to reboot - three weeks worth of simulation has to be > halted. > > PetterArticle: 32392
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.Article: 32393
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: 32395
As far as I know Xilinx has published bitstream Information on the xc6200 line (now defunct) and some information on the Virtex family. The Virtex information is in XAPP 151 "Virtex Configuration Architecture Advanced Users Guide." We use that information to dynamically configure a target system through the select map. We designed a microcoded state machine / controller that consists of a single Block Ram and 20 CLBs in a Virtex or VirtexE. We read a placed and routed design (.ncd) into what we call a "FPGA Browser" where you can select a block ram. You can change that Ram while the Virtex is running live. If that Ram is a controller ram you can pop up the "C" code and edit that then download directly into the running Virtex system. It takes less than 1 second to compile your code and download the resulting partial configuration bitstream. The controller runs at 125 MHz. To use the controller you connect the state bits up to Flip-flop clock enables and mux controls and other control bits of your design (resets or what not). The program then outputs bitstream data when connected live to a system or INIT_xx style initialization data for the UCF file. What is great about this approach (IMHO) is that you can change the behavior of your design without changing the design itself (in that all routing and placement are held 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. Steve Casselman, President Virtual Computer Corporation www.vcc.com "Alfredo Benso" <alfredo.benso@tiscalinet.it> wrote in message news:9fgaom$opj$1@menelao.polito.it... > Hi everybody, > I am a researcher at Politecnico di Torino in Italy. > I am looking for information about the format of the Xilinx configuration > bit stream. Is the format public? Is there some document or file available > explaining how to generate a stream of configuration bits for a Xiling FPGA? > > Anybody can help? > > Thanks Alfredo > > ----ooo---ooo---ooo---ooo---- > BENSO Alfredo, PhD > > Politecnico di Torino > > Dip. Automatica e Informatica > > C.so Duca degli Abruzzi 24 > > Torino - Italy > > Phone: +39-011-564.7080 > > Fax: +39-011-564.7099 > > email: alfredo.benso@polito.it > > ----------ooo---ooo------------- > > > > >Article: 32396
You have to make sure that you simulate the average behavior of the circuit, not the things you would normally like to simulate. For example, you would normally not simulate the one million clock ticks of a 20-bit counter. You would simulate it from shortly before to shortly after Terminal Count. That's not the typical power consumption! Sorry for this simplistic example ( counter power is actually very easy to estimate) but I always point out the difficulty of determining "average" patterns. Peter Alfke, Xilinx Applications > > > Phil Hays wrote: > > > > > 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. > > -- > > Phil HaysArticle: 32397
Peter, The retiming feature in synplicity is supposed to redistribute the registers in a pipeline to equalize the delays between, so although putting the registers in at the end of the pipe is meaningless by itself, when taken together with retiming software, it provides the information the tools need to generate a pipeline with the delays distributed between the combinatorial logic instead of bunched up at the end. Alan, I haven't tried the retimign feature in synplicity yet. Synplicity will reduce strings of flip-flops to SRL16's if they are simple flip-flops with no resets. You can keep it from doing that by putting a global reset on the FFs or syn_preserve=true attributes on the intermediate signals. I'm not sure if the syn_preserve will work with the retiming, but that is where I'd probably start. As for the making timing worse, that is most likely because when synplicity does convert flip-flops to SRL16's, it does it to all of them in the chain. The clock to out of the SRL16 is comparatively quite poor, which is not really a problem if it is driving the d input of the flip-flop in the same slice, but does add considerably to the delay if it is driving a different flip-flop, because of the routing and LUT delays. The proper way to use SRL16's is to reduce the number of FF's by one and then feed the Q through an FD or FDE. Unfortunately, synplicity does not do that automatically. It's a shame since that flip-flop really can't be used for anything else anyway due to routing restrictions. Finally, I presume you are using synplify pro 6.2.4. I don't believe the 'amateur' version supports retiming. (I use the 'amateur' version, I couldn't justify the additional cost of the Pro version for the type of work I am doing). 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. Peter Alfke wrote: > I have a feeling that you mix up two things: > Pipelining breaks up long combinatorial paths and inserts a flip-flop, so > that tha clock can run faster. > > If you do this indiscriminately, you may get into a situation where two > branches of logic must meet, but they have different numbers of pipeline > stages. You must compensate this and "balance" the number of flip-flops, so > that the branches have the same number of pipeline delays. It's obvious if > you think about it. > And SRL16s are ideally suited to implement several cascaded flip-flops. > > Just cascading flip-flops at the end of a combinatorial chain is > meaningless, unless it is needed for balancing purposes. You got the higher > speed from breaking up the combinatorial chains... > > Peter Alfke, Xilinx Applications > ================================ > Alan Nishioka wrote: > > > Does FPGA Express do register balancing? > > > > Synplicity calls this "retiming". The idea is to take a large block of > > combinatorial code and move registers into it to speed up the clock > > speed. > > > > Then you would define a multiplier (for example) as a large > > combinatorial block and simply add registers to the output until it > > meets your timing requirement. > > > > I have seen this used in ASIC code, but I have not seen it work for > > FPGA's. > > > > I have been trying to get Synplify Pro 6.2.4, which supports retiming, > > to do this with no success. When I add more than a couple of registers > > to the output, it turns them into an SRL and makes it *slower*. > > > > I am using Xilinx XCV1000E, Synplify Pro 6.2.4, Xilinx Alliance 3.3.08i, > > Win2K, Netscape 4.75, Red Hat Linux 5.2, Flash 5, Acrobat 4.0 > > > > Alan Nishioka > > alann@accom.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: 32398
Rick,
I don't bother with the synplify attribute for the IOs. They don't seem to
work consistently, and frankly it isn't worth the time diddling around with
it when it is likely to change behavior in the next release. The xilinx
mapper will push the FF's to the IOBs if you set the IOB FF's option
appropriately provided the rules are met for the IOB FFs. That means no
feedback from output flip-flops and no inverters on the pin side of either
input or output. The inputs should meet the rules in most cases. For the
outputs, if it is a signal that is also used inside the FPGA, you need to
duplicate the flip-flop, one for the IOB and one for the internal signal .
The problem of course, is that synplify tends to merge that duplicated FF
back into one FF, or in the case of more than one FF in a chain, infers an
SRL16 (if there is no reset). You can avoid the merging of duplicated FFs
by putting syn_keeps on the d inputs to the flip-flops (syn_preserve
doesn't seem to prevent merging ff's). That will also prevent merging of
the final FF into an SRL16. The SRL16 inference can also be avoided by
putting a global reset on the flip-flops.
attribute syn_keep:boolean;
attribute syn_keep of iob_FF_d:signal is true;
attribute syn_keep of internal_FF_d:signal is true;
begin
iob_FF_d<=FF_d;
internal_FF_d<= FF_d;
process(clk)
begin
if clk'event and clk='1' then
iob_FF_q<=iob_ff_d;
internal_ff_q<=internal_ff_d;
end if;
end process;
Rick Collins wrote:
> 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 FAX
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
Article: 32399The edif netlist black boxes have to either be xilinx primitives or must link to another edif netlist for the black box. The M2_1B2 unisim element is not a primitive, rather it is a macro, therefore when it is instantiated, there must be a matching netlist that can be linked from the edif netlist. AFAIK, there are no already compiled netlists for the unisim macros. You can either compile these yourself and put them in the same directory as your design edif netlist (cumbersome at best), or you can avoid using anything other than unisim primitives. BTW, the library guide indicates which are primitives and which are macros. To do combinatorial logic, I put the (max 4 input) function in a separate VHDL entity and include the synplicity xc_map attribute. This essentially turns the logic into a LUT, which you can then instantiate in your design as well as decorate with user attributes for placement. I find this is more readable and less error prone than the alternative of using LUTs directly with an initialization vector. Charles Ross wrote: > Ray - > > Thank you VERY much. They were exactly where you said they were, and the > xilinx website showed me how to compile them in modelsim. I appreciate the > help. > > But now im hitting some new snags... > > Context: > For synthesis We're using Synplify 6.2.0, and foundation 3.3ip8 for > Virtex1000 and Virtex200E based Annapolis Microsystem Boards. > > Heres a small snippet of my vhdl code: > > -- synthesis translate_off > Library UNISIM; > use UNISIM.all; > -- synthesis translate_on > > entity TEST is > > -- snip (portmap) > > end TEST; > > architecture BEHAVIOR of TEST is > > -- snip (signal declarations etc.. ) > > attribute syn_black_box : boolean; > component M2_1B2 > port ( > S0 : in std_logic; > D0 : in std_logic; > D1 : in std_logic; > O : out std_logic); > end component; > attribute syn_black_box of M2_1B2 : component is true; > begin > > --snip irrelivant vhdl > > testmux : M2_1B2 port map(S0 => select, > D0 => a, > D1 => b, > O => out); > > -- snip MORE irrelivant vhdl > > end BEHAVIOR; > > When I compile this in synplify, I get a little black box in the edf file... > But when I get down to the ngdbuild phase I get: > > ERROR:NgdBuild:432 - logical block > '........./textmux' with type 'M2_1B2' is > unexpanded > > ------------------- > > Heres my real questions: > > Do I need to have anything in my synplify prj file (like the vhdl for the > unisim libraries)? or will simply using the component declarations in the vhdl > like above work? Do I even need to include those compnent declarations? Im > having nightmares down the road of making many entity which use of these > unisim compnents. If I have to make the complete list of each of the > components I use in each entity, so be it... but I am hoping there is a nicer > way to do it. > > I know I will need to include the (now precompiled) unisim library when doing > simulation, but im not positive that I can just ignore it completely in the > synthesis step. > > Do I need to do anything at the level of the foundation tools to make them > find these components? or should they be there already? > > Again... Sorry to be asking what are probably VERY basic questions, but you > have to start someplace. Thanks again > > Ray Andraka wrote: > > > The unisim source should be in your xilinx install directory under > > $XILINX/vhdl/src/unisims. You'll need to compile the library for your > > simulator. There are instructions available in the answers database on the > > xilinx website. If you can't find them there, I'm pretty sure you can > > download them from xilinx's website, but I'm not sure exactly where they > > are. If you can't find them there, Aldec has them on their website under > > the downloads, although you should probably check the version, it may not > > be the latest. > > -- > _____ _____ > ___ | | __ | > |___| | --| -| > |_____|__|__| -- -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