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
How to I design a circuit involving XC3000 with Xilinx ISE student edition? I look through the components and parts, but couldn't find the XC3000 series. I only found Virtex, Spartan, XC4000 but not XC3000 series. And also, my school uses Xilinx Foundation Series software for designing circuits with XC3000. Is it possible for me to save the .SCH file from school and open it in my Xilinx ISE student edition? and vice versa? Thank you.Article: 59476
jim thought - >My understanding is the 'free' version is a 6 month demo, and $$$ are >needed for more than that ? > Lattice also do not have a separate ABEL download, but instead have one >very large bundle. > Seems there would be an opening for a smaller download, of ABEL only, >for SPLD and CPLDs (eg new 4000 family ) ? > >-jg Well, the free license expires in 6 months, and you can always get another free license in 6months, so it'll never cost more than a minute on the weblicense page. Yes, you do need to download a fairly large file, but we have split up the d/l so you can get just the minimum (still 63 mb :( ) required. Mike Thomas LSC FAEArticle: 59477
Hi all, I've been working with the Xilinx Webpack on FPGA designs for a few months with good success. A recent design is approaching full device utilization and parts of my design are breaking because they no longer meet timing constraints. Being a newbie, I suspect that some of the layout tools and timing constraint managers need to be employed to tweak my design back into shape, but I'm having trouble figuring out how to use these. I'm wondering if there is some good documentation out there for how to do this, namely with Xilinx -- or better yet, a book of some sort (?) I can find lots of information of HDLs for synthesis, but no information on how to effectively squeeze performance out of an already synthesized design. Maybe this is the million dollar question... Any help would be greatly appreciated! Best regards, Bill DiehlsArticle: 59478
Joe, Rather than rant here in public (about things that are not true), I would encourage you to contact our Hi_Rel Group through your FAE/distributor. If you do not know who to contact, contact me directly, and I will find the correct person for you. Just because the newest tool suite does not support these Q-Pro and mil-spec devices doesn't mean we don't support them for the mil-spec business. Austin JoeG wrote: > I've asked Xilinx the question about legacy support for years. We have > hundreds of XC4000 series parts fielded on MILITARY > applications. Specifically, we literally have hundreds of these > XC4000(militarized parts) devices fielded on DDG-51 Class Destroyers - the > hub of the US Navy. We need to maintain and support these ships for another > 20 yrs. However Xilinx newer tool suites ISE(neither did the Alliance) DO > NOT support these legacy devices. Only the legacy XACT series s/w supported > these parts > > Xilinx and distributors have always touted the fact that their SRAM FPGAs > extend the tail end design of the product lifecycle by allowing upgrades to > the FIELDED products. However, we CAN'T do this unless the current tool > offered by Xilinx supports the older legacy devices such as the XC4000. > > This is NOT acceptable, as the old tools are not supported by Xilinx, > maintaining the old tools, old platforms(SunWorkstations) and older > operating systems may NOT be possible or feasible. > > So we are STUCK with maintaining an OLD machine with OLD Xilinx XACT > software. > > JoeGArticle: 59479
Louis, Too bad you ran out of resources, and can not change its design. I suspect that the only way to get around this is to check the timing and the routing using FPGA_Editor, and hand fix any places where the timing is vilolated. More constraints may cause the design to become unroutable once you run out of resources. Austin louis lin wrote: > Thank you very much for your suggestion. > The protection and redundancy requirements of our system > exhausted all global clocks. > Is the manual routing the only solution? > Or I can add some constraint to the P&R tool? > Besides, the "timing report" means P&R report or Timing Analyzer report? > > ----- Original Message ----- > From: "Austin Lesea" <Austin.Lesea@xilinx.com> > Newsgroups: comp.arch.fpga > Sent: Monday, August 18, 2003 10:41 PM > Subject: Re: Skew on a clock tree on a virtex II : what is the good figure ? > > : Louis, > : > : You will get timing voilations in your timing report. > : > : As well, you may have to additionally manually route the clock lines to registers so that > the > : clock always gets to the ff's before the data (no warnings for this). That is what you > lose > : when you run out of global clocks. > : > : I suggest that you re-design your circuitry to use fewer global clocks, and more clock > enables > : (which one can always do). > : > : Austin > : > : louis lin wrote: > : > : > Sometimes I can't help using non-clock net for low fan-out clock > : > because all clock nets were consumed. > : > Will the P&R tools report any warning or error > : > when it can't overcome the skew? > : > How can I realize if the skew cause any timing violation? > : >Article: 59480
On Tue, 19 Aug 2003 19:32:27 -0700, Jeff Sampson wrote: > I remember back when I used Xilinx XC95xx CPLDs that Xilinx was bragging > about the pin locking capabilities of the 9500 series. And the few > designs that I did always routed to the assignment that I gave the pins. > > Do the FPGAs have that kind of success? Or do people end up have to > redesign boards when they change the logic? (I can't imagine that.) > > I have given up on the Spartan II chips for my prototyping system. I > decided the 3.3V I/O was going to be too much screwing around to > interface with my other 5V parts. The reason is that I want to randomly > assign any pin as input or output and have it be 5V in or out > respectively. So I'll put my Spartan II chips on the shelf for stage 2 > develepment. (ie. first PCB prototype where I can group outputs into 8 > or 16 bit chunks and use level translator chips.) > Why do you think that you need level translators for Spartan II? SpartanII inputs are fully 5V compatible. SpartanII outputs will not swing to 5V but neither will TTL/LSTTL/SOME FCTs/GALS etc. Unless you need to interface to 5V HC series parts there is no need for the outputs to swing to 5V for logic/memory interfacing. Other than straight HC CMOS parts its hard to find chips that want a VIH higher than 3.3V... And it is possible to get 5V swing if needed by using open drain mode and external pullups. Peter Wallace > So I'm back to either XC31xxA or XC52xx parts. I can easily get these > parts and my software supports them. (I could probably get Spartan 1 > parts if I really tried hard. But the ones I have found are pretty > pricey.) > > I want to make a board similar to my CPLD board: > > http://www.infinetivity.com/~jsampson/qprot/qprot.htm > > I just don't want to go to the trouble of making the board with a bunch > of connectors and find out the PAR won't assign the bits on my > connectors. My designs will probably be lean on logic usage so I assume > that greatly improves my chances of successful routing. > > On the CPLD I tried to group the 8-bits of the connector to the same > function block. Is that necessary on the FPGAs? The XC3000 data sheet > doesn't even seem to group them. They are just labled "I/O" on the pin > listing.Article: 59481
The XC3000 is to a modern FPGA what a '286 is to a Pentium4. Would your professors suggest you use a '286? It's a capable computer, but hopelessly obsolete and underpowered. So is the XC3000. Get with it and use Spartan or Virtex devices. "One year in the life of an FPGA is like 15 years in a human". By that rule, your XC3000s should be in the old folks' home or the cemetary. Peter Alfke, Xilinx ===================== Terry wrote: > > How to I design a circuit involving XC3000 with Xilinx ISE student > edition? I look through the components and parts, but couldn't find the > XC3000 series. I only found Virtex, Spartan, XC4000 but not XC3000 series. > > And also, my school uses Xilinx Foundation Series software for designing > circuits with XC3000. Is it possible for me to save the .SCH file > from school and open it in my Xilinx ISE student edition? and vice versa? > > Thank you.Article: 59482
Symon <symon_brewer@hotmail.com> wrote in message news:a28bc07f.0308190944.9b2bd98@posting.google.com... > Hi Jonathan, > I thought about doing this in perl a while back but didn't get > round to it. Sounds like Tcl could be promising, I like 'easy'! Do you > have any recommendations of where a hardware engineer could start to > learn about Tcl? Any books you like? > thanks, Syms. Symon, From what Jonathon said it sounds like it's easier in Tcl than in Perl, but it's not that hard in Perl. You'll need Win32-SerialPort.zip and Win32-API.ppd which it uses. Win32-Api.ppd is a normal ppm install, the serial port stuff isn't but it's fairly self explanatory when you unzip it. These can be got from... http://ppm.activestate.com/PPMPackages/ If you do a Google Groups search on "Win32 API" Author "Nial" you'll find a post from me on the 6th Sept 2001 explaining how I installed Win32-Api. Having said that I've just checked and Win32-SerialPort is only listed under 5XX builds but I've a feeling it'll work with later builds as it's not an RPM install. It's worth a play, when you unzip it there's a README file that explains what's going on. There are also a few demo scripts in the eg directory. The debugger shown here... http://www.nialstewartdevelopments.co.uk/perl.htm ..was built on this and saved me a hell of a lot of time. Send me an email and I'll send you the script as an example if you want. Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 59483
"Peter Alfke" <peter@xilinx.com> wrote in message news:3F4396CA.FC62CB8D@xilinx.com... > The XC3000 is to a modern FPGA what a '286 is to a Pentium4. Would your > professors suggest you use a '286? It's a capable computer, but > hopelessly obsolete and underpowered. So is the XC3000. > Get with it and use Spartan or Virtex devices. > "One year in the life of an FPGA is like 15 years in a human". > By that rule, your XC3000s should be in the old folks' home or the cemetary. Hmmm... Peter, I suspect you are not quite so aware of the constraints on typical college lecturers and support departments as I am :-) Every change of infrastructure entrains a mountain of work: typically, haggling with central IT services to allow a piece of software to be installed; fighting for budget to replace obsolete demo hardware (and don't forget that you probably need to replace a class set); rewriting endless class teaching material, and reprinting it all. In the "real world" the cost of this sort of infrastructure shift is covered by the productivity gains you get from the new stuff; in teaching, it's all downside - you get the cost, but no gain; but if you don't spend the effort, pain comes later with software incompatibility and general unsupportedness. And no, you can't simply mothball a set of machines to run the old software. The college's central IT services will probably forbid the installation of "untrustworthy" software like this WebPack doohickey they've never heard of, but will without a qualm update the entire network from NT to XP or whatever happens to suit the sysadmin's purpose, so elderly software will eventually become unusable. So the poor beleaguered lecturers hang on to what they know for as long as they can, until external pressures force them to change. There's no smooth continuous stream of project- funded design starts to encourage incremental upgrading. I got out of that world a few years back. I miss much about it, but I certainly have no nostalgia for the fights to keep even halfways up-to-date with practical and lab material. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 59484
Hi Jonathan,
Thanks mate, the advice is much appreciated. As you were so
helpful :-) I'll back up your brazen course plug by saying the Doulos
VHDL course's very good too. I've still got my little Golden Reference
Guide, at least I have when people aren't borrowing it!
cheers, Syms.
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:<bhvaf5$40i$1$830fa79d@news.demon.co.uk>...
> Start at www.tcl.tk and download Tcl/Tk 8.4.4. It comes with
> various demos and comprehensive help. There's also a bunch of
> other links on that site, including some tutorial material.
>
> I have a very soft spot for the splendid Tcl-for-hardware-people
> course that we offer at http://www.doulos.com/frtcl.html :-)
> Seriously, it's very unusual to find a course targeted at
> hardware people and EDA applications...
>
>
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
Article: 59485It wasn't a rant but an honest question -- after re-reading my post I noticed I transposed the words "we" and "are" in the final sentence. So are we STUCK with maintaining an OLD machine with OLD Xilinx XACT software --- BTW I've already asked my rep, distrib, and Xilinx the same question -- they all said you need to keep the OLD XACT software and maintain an old Workstation -- again NOT acceptable. "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F438AAA.6150A63A@xilinx.com... > Joe, > > Rather than rant here in public (about things that are not true), I would > encourage you to contact our Hi_Rel Group through your FAE/distributor. > > If you do not know who to contact, contact me directly, and I will find the > correct person for you. > > Just because the newest tool suite does not support these Q-Pro and mil-spec > devices doesn't mean we don't support them for the mil-spec business. > > Austin > > JoeG wrote: > > > I've asked Xilinx the question about legacy support for years. We have > > hundreds of XC4000 series parts fielded on MILITARY > > applications. Specifically, we literally have hundreds of these > > XC4000(militarized parts) devices fielded on DDG-51 Class Destroyers - the > > hub of the US Navy. We need to maintain and support these ships for another > > 20 yrs. However Xilinx newer tool suites ISE(neither did the Alliance) DO > > NOT support these legacy devices. Only the legacy XACT series s/w supported > > these parts > > > > Xilinx and distributors have always touted the fact that their SRAM FPGAs > > extend the tail end design of the product lifecycle by allowing upgrades to > > the FIELDED products. However, we CAN'T do this unless the current tool > > offered by Xilinx supports the older legacy devices such as the XC4000. > > > > This is NOT acceptable, as the old tools are not supported by Xilinx, > > maintaining the old tools, old platforms(SunWorkstations) and older > > operating systems may NOT be possible or feasible. > > > > So we are STUCK with maintaining an OLD machine with OLD Xilinx XACT > > software. > > > > JoeG >Article: 59486
We literally have hundreds of PALs/GALs to maintain. Nevertheless after one migrates from ABEL to VHDL or Verilog which tool can target the code to a 22V10 these days? JoeG "Andrew Paule" <lsboogy@qwest.net> wrote in message news:sQD0b.1565$br1.56228@news.uswest.net... > Just convert your abel code to verilog - it's easy, and then you don't > have to worry about it for a few more years. You can do the conversion > for a PAL (16xx,20xx, 22xx) in an hour or so. > > Andrew > > JoeG wrote: > > >Who has current design tools that will maintain legacy 22V10 design using > >ABEL? We used to use DataIO's ABEL package and Minc Synario's ABEL(before > >Xilinx swallowed them). > > > >Thanks in advance > > > >JoeG > > > > > > > > >Article: 59487
"JoeG" <JoeG@nowhere.net> wrote in message news:HJxHK0.LHr@news.boeing.com... > It wasn't a rant but an honest question -- after re-reading my post I > noticed I transposed the words "we" and "are" in the final sentence. You also forgot the question mark.Article: 59488
Joe, You are correct: there is a 'hole' here. Have looked into it, and the present "official" response is to archive your software (and support computers) to support the older designs for the standard commercial customer. For the military/high-rel customer, there is no real policy (I was more optomistic, but I turned out to be wrong -- no one had really sat down and thought it through for mil-spec). There are other business models which also require a much longer term support method (such as automotive), so you are not 'alone.' This is an area that we are now looking at. Thank you for bringing it to our attention as a deficiency. We archive all software, and we are able to run any older version to resolve customer issues, so if you do have an issue, please open a webcase for support. Just make sure that you have your older designs fully archived so we are able to help out. Austin JoeG wrote: > It wasn't a rant but an honest question -- after re-reading my post I > noticed I transposed the words "we" and "are" in the final sentence. > > So are we STUCK with maintaining an OLD machine with OLD Xilinx XACT > software --- > > BTW I've already asked my rep, distrib, and Xilinx the same question -- they > all said you need to keep the OLD XACT software and maintain an old > Workstation -- again NOT acceptable. > > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3F438AAA.6150A63A@xilinx.com... > > Joe, > > > > Rather than rant here in public (about things that are not true), I would > > encourage you to contact our Hi_Rel Group through your FAE/distributor. > > > > If you do not know who to contact, contact me directly, and I will find > the > > correct person for you. > > > > Just because the newest tool suite does not support these Q-Pro and > mil-spec > > devices doesn't mean we don't support them for the mil-spec business. > > > > Austin > > > > JoeG wrote: > > > > > I've asked Xilinx the question about legacy support for years. We have > > > hundreds of XC4000 series parts fielded on MILITARY > > > applications. Specifically, we literally have hundreds of these > > > XC4000(militarized parts) devices fielded on DDG-51 Class Destroyers - > the > > > hub of the US Navy. We need to maintain and support these ships for > another > > > 20 yrs. However Xilinx newer tool suites ISE(neither did the Alliance) > DO > > > NOT support these legacy devices. Only the legacy XACT series s/w > supported > > > these parts > > > > > > Xilinx and distributors have always touted the fact that their SRAM > FPGAs > > > extend the tail end design of the product lifecycle by allowing > upgrades to > > > the FIELDED products. However, we CAN'T do this unless the current tool > > > offered by Xilinx supports the older legacy devices such as the XC4000. > > > > > > This is NOT acceptable, as the old tools are not supported by Xilinx, > > > maintaining the old tools, old platforms(SunWorkstations) and older > > > operating systems may NOT be possible or feasible. > > > > > > So we are STUCK with maintaining an OLD machine with OLD Xilinx XACT > > > software. > > > > > > JoeG > >Article: 59489
I have several military and aerospace customers using xilinx XC4K parts, and do have the software with them which they happily maintain. However, all their latest designs are using the Virtex series parts with latest version softwares. This link called the "ISE Classics" on xilinx.com might help you, where Xilinx has put the older software that supports XC4K and other Spartan/XL P&R as an archive, which can be downloaded free. http://www.xilinx.com/webpack/classics/index.htm --neeraj "JoeG" <JoeG@nowhere.net> wrote in message news:HJxHK0.LHr@news.boeing.com... > It wasn't a rant but an honest question -- after re-reading my post I > noticed I transposed the words "we" and "are" in the final sentence. > > So are we STUCK with maintaining an OLD machine with OLD Xilinx XACT > software --- > > > BTW I've already asked my rep, distrib, and Xilinx the same question -- they > all said you need to keep the OLD XACT software and maintain an old > Workstation -- again NOT acceptable. > > > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3F438AAA.6150A63A@xilinx.com... > > Joe, > > > > Rather than rant here in public (about things that are not true), I would > > encourage you to contact our Hi_Rel Group through your FAE/distributor. > > > > If you do not know who to contact, contact me directly, and I will find > the > > correct person for you. > > > > Just because the newest tool suite does not support these Q-Pro and > mil-spec > > devices doesn't mean we don't support them for the mil-spec business. > > > > Austin > > > > JoeG wrote: > > > > > I've asked Xilinx the question about legacy support for years. We have > > > hundreds of XC4000 series parts fielded on MILITARY > > > applications. Specifically, we literally have hundreds of these > > > XC4000(militarized parts) devices fielded on DDG-51 Class Destroyers - > the > > > hub of the US Navy. We need to maintain and support these ships for > another > > > 20 yrs. However Xilinx newer tool suites ISE(neither did the Alliance) > DO > > > NOT support these legacy devices. Only the legacy XACT series s/w > supported > > > these parts > > > > > > Xilinx and distributors have always touted the fact that their SRAM > FPGAs > > > extend the tail end design of the product lifecycle by allowing > upgrades to > > > the FIELDED products. However, we CAN'T do this unless the current tool > > > offered by Xilinx supports the older legacy devices such as the XC4000. > > > > > > This is NOT acceptable, as the old tools are not supported by Xilinx, > > > maintaining the old tools, old platforms(SunWorkstations) and older > > > operating systems may NOT be possible or feasible. > > > > > > So we are STUCK with maintaining an OLD machine with OLD Xilinx XACT > > > software. > > > > > > JoeG > > > >Article: 59490
On Wed, 20 Aug 2003 17:21:37 GMT, "JoeG" <JoeG@nowhere.net> wrote: >It wasn't a rant but an honest question -- after re-reading my post I >noticed I transposed the words "we" and "are" in the final sentence. > >So are we STUCK with maintaining an OLD machine with OLD Xilinx XACT >software --- > > >BTW I've already asked my rep, distrib, and Xilinx the same question -- they >all said you need to keep the OLD XACT software and maintain an old >Workstation -- again NOT acceptable. While I have no great solution for the old software, I have a pretty good solution for old operating systems and old systems to run them on. I use a fine product called VMWare www.vmware.com . With it and a few spare gigabytes of disk on my current machine, I maintain over a dozen different legacy systems, each with the OS of choice for that legacy sw, and an environment that lets it run. I also use it for project isolation, for testing out new versions of sw that I don't trust to run on my "real" machine, and for isolation of packages that may interfere with each other. Given the current cost of IDE disks at below $1.00 per gigabyte, I get a complete, safe, encapsulated, archived computer for less than a few dollars, and no physical space in my office. In total, I maintain about 20 such legacy/test/isolation computers in a 80 gigabyte partition (about 50 GB used), for the cost of about $70 Philip Freidin Philip Freidin FliptronicsArticle: 59491
The tools already know you want it to be fast, it can be a tough row to hoe to try to beat the tools on placement. Your best bet is architecture enhancements that it can't do on its own. Think of pipelining more. Bigger part too. Regards Bill Diehls <billabloke@yahoo.com> wrote in message news:<aus6kvggsip6vhhgce8tsnktp8ev43dmcb@4ax.com>... > Hi all, > I've been working with the Xilinx Webpack on FPGA designs for a few > months with good success. A recent design is approaching full device > utilization and parts of my design are breaking because they no longer > meet timing constraints. > > Being a newbie, I suspect that some of the layout tools and timing > constraint managers need to be employed to tweak my design back into > shape, but I'm having trouble figuring out how to use these. I'm > wondering if there is some good documentation out there for how to do > this, namely with Xilinx -- or better yet, a book of some sort (?) > > I can find lots of information of HDLs for synthesis, but no > information on how to effectively squeeze performance out of an > already synthesized design. Maybe this is the million dollar > question... Any help would be greatly appreciated! > > Best regards, > Bill DiehlsArticle: 59492
Hi could anybody tell me how to tell the XST or Leonardo that I want the RAM module I write to be implemented as a BlockRAM not a distributed one? XST says you're using a mode not supported in Spartan II BlockRAMs. I can't figure it out.Article: 59493
Pete, Austin, Neeraj et.al. Thanks for all of your fine responses and feedback ... JoeGArticle: 59494
Here is a dual port (read) block ram that will synthesize properly in
Leonardo, I'm not sure about XST.
Tom Dillon
Dillon Engineering
www.dilloneng.com
library work, ieee;
use work.all;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity comp_vhdlmem_rw_Ram_0 is
port ( port_addr_out : in std_logic_vector(10
downto 0);
port_we : in std_logic;
port_clk : in std_logic;
port_data_out_1 : out std_logic_vector(13
downto 0) := (others => '0');
port_data_out : out std_logic_vector(13
downto 0) := (others => '0');
port_addr_in : in std_logic_vector(10
downto 0);
port_data_in : in std_logic_vector(13
downto 0) );
end entity comp_vhdlmem_rw_Ram_0;
architecture arch of comp_vhdlmem_rw_Ram_0 is
type mem_type is array (1535 downto 0) of STD_LOGIC_VECTOR (13 downto 0);
signal mem : mem_type;
signal addr_in_i1, addr_out_i1, addr_in_i2, addr_out_i2 :
std_logic_vector(10 downto 0) := (others => '0');
attribute syn_ramstyle : string;
attribute syn_ramstyle of mem : signal is "block_ram";
begin
addr_in_i1 <= port_addr_in;
addr_out_i1 <= port_addr_out;
process (port_clk) is
begin
if rising_edge(port_clk) then
addr_out_i2 <= addr_out_i1;
addr_in_i2 <= addr_in_i1;
if port_we = '1' then
mem(conv_integer(addr_in_i1)) <= port_data_in;
end if;
end if;
end process;
port_data_out_1 <= mem(conv_integer(addr_in_i2));
port_data_out <= mem(conv_integer(addr_out_i2));
end architecture arch;
senjed wrote:
> Hi
> could anybody tell me how to tell the XST or Leonardo that I want the
> RAM module I write to be implemented as a BlockRAM not a distributed
> one? XST says you're using a mode not supported in Spartan II BlockRAMs.
> I can't figure it out.
Article: 59495Peter Wallace wrote: > On Tue, 19 Aug 2003 19:32:27 -0700, Jeff Sampson wrote: >>I have given up on the Spartan II chips for my prototyping system. I >>decided the 3.3V I/O was going to be too much screwing around to >>interface with my other 5V parts. The reason is that I want to randomly >>assign any pin as input or output and have it be 5V in or out >>respectively. So I'll put my Spartan II chips on the shelf for stage 2 >>develepment. (ie. first PCB prototype where I can group outputs into 8 >>or 16 bit chunks and use level translator chips.) > > > Why do you think that you need level translators for Spartan II? > SpartanII inputs are fully 5V compatible. SpartanII outputs will not > swing to 5V but neither will TTL/LSTTL/SOME FCTs/GALS etc. Unless you > need to interface to 5V HC series parts there is no need for the outputs > to swing to 5V for logic/memory interfacing. Other than straight HC CMOS > parts its hard to find chips that want a VIH higher than 3.3V... > > And it is possible to get 5V swing if needed by using open drain > mode and external pullups. > > > Peter Wallace Uhhh... Uhhh... I guess because the big tables of I/O standards that I didn't recognize scared me. ;-) And then Peter pointed out that 5V tolerant doesn't mean 5V tolerant and quoted using limiting resistors. But I tried to balance that with statements like "You can lead a 286 to water, but you can't make it drink." :-) So I went back and checked the spec sheets for the parts I already have defined: > Part ViL ViH VoL VoH > > IDT 7208 FIFO 0.8 2.0 0.4 2.4 > KM681000 RAM 0.8 2.2 0.4 2.4 > ADC1175 1.0 3.0 0.4 2.4 > LM1881 - - 0.8 4.5 > OV5017 Imager 0.8 2.0 0.6 2.4 > > The ATMega103L on the STK300 board can run at 5V or 3.3V. [If I use a big part like Spartan then I probably don't need an external FIFO] I see that the only one that may not work seems to be the ADC1175. So open drain and a pullup to 5V? So, do I just default all inputs to LVTTL? This gives me 5V tolerance and doesn't require VREF. Can all outputs also default to LVTTL? Or is one of the PCI standards a better choice? Except outputs that have to swing higher, then would I use OBUF_GTL and an extertnal pullup for those? And can I do OBUFT_GTL with external pullup? If I do a bidirectional do I use IOBUF_GTL with external pullup? But that sets up a diferential input buffer. Maybe I'll just avoid using bidirectional with a 5V swing. Will setting GTL require the VREF pin? Or is there another way to specify open drain? If I can specify it directly then I could run LVTTL and tell it the output is open drain. [I'm sorry to be such a pain about this. Does Xilinx have an APP note or White Paper about 5V interfacing?] -- Jeff Sampson http://tcrobots.org/members/jsamp.htmArticle: 59496
Philip, What a great idea.... Austin Philip Freidin wrote: > On Wed, 20 Aug 2003 17:21:37 GMT, "JoeG" <JoeG@nowhere.net> wrote: > >It wasn't a rant but an honest question -- after re-reading my post I > >noticed I transposed the words "we" and "are" in the final sentence. > > > >So are we STUCK with maintaining an OLD machine with OLD Xilinx XACT > >software --- > > > > > >BTW I've already asked my rep, distrib, and Xilinx the same question -- they > >all said you need to keep the OLD XACT software and maintain an old > >Workstation -- again NOT acceptable. > > While I have no great solution for the old software, I have a pretty > good solution for old operating systems and old systems to run them > on. I use a fine product called VMWare www.vmware.com . With it > and a few spare gigabytes of disk on my current machine, I maintain > over a dozen different legacy systems, each with the OS of choice > for that legacy sw, and an environment that lets it run. I also > use it for project isolation, for testing out new versions of sw > that I don't trust to run on my "real" machine, and for isolation > of packages that may interfere with each other. > > Given the current cost of IDE disks at below $1.00 per gigabyte, > I get a complete, safe, encapsulated, archived computer for less > than a few dollars, and no physical space in my office. In total, > I maintain about 20 such legacy/test/isolation computers in a > 80 gigabyte partition (about 50 GB used), for the cost of about > $70 > > Philip Freidin > > Philip Freidin > FliptronicsArticle: 59497
All, Start with: http://www.xilinx.com/xapp/xapp080.pdf Moving on to: Answer Record # 8654: Virtex/-E/-II - Are input and output (I/Os) 5V tolerant? And to: Answer Record # 13542: Spartan-IIE - Are the I/Os 5V-tolerant? And: Answer Record # 11313: Spartan-II/Spartan-IIE - Are Spartan-II and Spartan-IIE I/Os 5V-tolerant? Not to mention: Answer Record # 10835: Virtex-II/Virtex-II Pro I/O - Are Virtex-II/Pro I/Os 5V-tolerant? Can I drive I/O with a higher voltage? And: Answer Record # 2505: Mixed Voltage Systems: Interfacing 3.3 Volt and 5 Volt devices. Lots of details on this subject on line......just put 5v inteface into the search engine, and push the go button. Last but not least, the all time classic: http://www.xilinx.com/xapp/xapp133.pdf which aplies to Virtex, and to Spartan II. Austin Jeff Sampson wrote: > Peter Wallace wrote: > > On Tue, 19 Aug 2003 19:32:27 -0700, Jeff Sampson wrote: > > >>I have given up on the Spartan II chips for my prototyping system. I > >>decided the 3.3V I/O was going to be too much screwing around to > >>interface with my other 5V parts. The reason is that I want to randomly > >>assign any pin as input or output and have it be 5V in or out > >>respectively. So I'll put my Spartan II chips on the shelf for stage 2 > >>develepment. (ie. first PCB prototype where I can group outputs into 8 > >>or 16 bit chunks and use level translator chips.) > > > > > > Why do you think that you need level translators for Spartan II? > > SpartanII inputs are fully 5V compatible. SpartanII outputs will not > > swing to 5V but neither will TTL/LSTTL/SOME FCTs/GALS etc. Unless you > > need to interface to 5V HC series parts there is no need for the outputs > > to swing to 5V for logic/memory interfacing. Other than straight HC CMOS > > parts its hard to find chips that want a VIH higher than 3.3V... > > > > And it is possible to get 5V swing if needed by using open drain > > mode and external pullups. > > > > > > Peter Wallace > > Uhhh... Uhhh... > > I guess because the big tables of I/O standards that I didn't recognize scared > me. ;-) And then Peter pointed out that 5V tolerant doesn't mean 5V tolerant > and quoted using limiting resistors. But I tried to balance that with statements > like "You can lead a 286 to water, but you can't make it drink." :-) > > So I went back and checked the spec sheets for the parts I already have defined: > > > Part ViL ViH VoL VoH > > > > IDT 7208 FIFO 0.8 2.0 0.4 2.4 > > KM681000 RAM 0.8 2.2 0.4 2.4 > > ADC1175 1.0 3.0 0.4 2.4 > > LM1881 - - 0.8 4.5 > > OV5017 Imager 0.8 2.0 0.6 2.4 > > > > The ATMega103L on the STK300 board can run at 5V or 3.3V. > > [If I use a big part like Spartan then I probably don't need an external FIFO] > > I see that the only one that may not work seems to be the ADC1175. So open drain > and a pullup to 5V? > > So, do I just default all inputs to LVTTL? This gives me 5V tolerance and > doesn't require VREF. Can all outputs also default to LVTTL? Or is one of the > PCI standards a better choice? Except outputs that have to swing higher, then > would I use OBUF_GTL and an extertnal pullup for those? > > And can I do OBUFT_GTL with external pullup? > > If I do a bidirectional do I use IOBUF_GTL with external pullup? But that sets > up a diferential input buffer. Maybe I'll just avoid using bidirectional with a > 5V swing. > > Will setting GTL require the VREF pin? Or is there another way to specify open > drain? If I can specify it directly then I could run LVTTL and tell it the > output is open drain. > > [I'm sorry to be such a pain about this. Does Xilinx have an APP note or White > Paper about 5V interfacing?] > > -- > Jeff Sampson > http://tcrobots.org/members/jsamp.htmArticle: 59498
Bill, I'm no expert, by far, but here are some pointers. Start by at least giving your tools clock frequency information. In your UCF file add something like this for each clock: NET "SDRAM_CLKIN_PAD" TNM_NET = "SDRAM_CLKIN_PAD"; #TIMESPEC "TS_SDRAM_CLKIN_PAD" = PERIOD "SDRAM_CLKIN_PAD" 7.5188 ns HIGH 50 %; TIMESPEC "TS_SDRAM_CLKIN_PAD" = PERIOD "SDRAM_CLKIN_PAD" 6.2000 ns HIGH 50 %; This is for a 133MHz SDRAM interface. The second line is commented out. The reason for commenting-out the real clock period and replacing it with a 6.2ns specification is to over-constrain the design. I don't know all the tricks yet, but it seems that you (sometimes) have to lie to the tools in order to get automated placement that works. Start with the actual numbers and experiment from there forward. The next step might be to use area constraints. Something that looks like this added to the UCF file, for example: INST "SDRAM_CONTROLLER*" AREA_GROUP = "grp_sdram_controller"; AREA_GROUP "grp_sdram_controller" RANGE = SLICE_X60Y52:SLICE_X63Y79 ; This forces the SDRAM_CONTROLLER logic to be placed and routed within the specified area within the device. Depending on your design (registerd inputs and outputs might help) this solution might prove to be very effective in avoiding autorouted/placed designs that break because you added just one line of code. I don't know if you got into forcing FF's to be placed on IOB's for example, that could helps a fast design as well. There's also hand-placement. But, this, from what I've learned, should be a last resort. Ray Andraka has a neat way to do this that makes a lot of sense. It does require VHDL (as I understand it) and, if you, like me, are using Verilog, I'm afraid this may not be an option for you. Also, the time to use it might be at the start of a project, not the end...like most things. There are issues and finer points with all of these constraints. Having a full understanding of this is certainly one of the distinctions between and expert and not. You'll find a information on all of these constraints in the appropriatedly named "Constraints Guide". There's a very useful PDF in the Xilinx site called "Understanding Timing and Placement Constraints". The file name is "timingcsts5i.pdf" and about 1.4 MB. The Xilinx site is notoriously horrible in terms of being able to find information (that's another subject), I apologize for not having a link for you. I can email it to you if you can't locate it. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Bill Diehls" <billabloke@yahoo.com> wrote in message news:aus6kvggsip6vhhgce8tsnktp8ev43dmcb@4ax.com... > Hi all, > I've been working with the Xilinx Webpack on FPGA designs for a few > months with good success. A recent design is approaching full device > utilization and parts of my design are breaking because they no longer > meet timing constraints. > > Being a newbie, I suspect that some of the layout tools and timing > constraint managers need to be employed to tweak my design back into > shape, but I'm having trouble figuring out how to use these. I'm > wondering if there is some good documentation out there for how to do > this, namely with Xilinx -- or better yet, a book of some sort (?) > > I can find lots of information of HDLs for synthesis, but no > information on how to effectively squeeze performance out of an > already synthesized design. Maybe this is the million dollar > question... Any help would be greatly appreciated! > > Best regards, > Bill DiehlsArticle: 59499
So, what happens if you get the signal showing up twice within one clock period? Do you need to detect it twice? You can use an input signal to set a register (input to clock, logic high to data) and reset the input edge detector when your state machine steps. I wonder, though, are you practicing safe sampling? If your state machine is advancing based on an asynchronous input, the state bits have to be carefully designed or you must first sychronize your inputs to the FSM clock. If an input is changing right around the FSM clock, some logic might see a logic low and others see a logic high; where does the state machine go? "Wong" <tatto0_2000@yahoo.com> wrote in message news:509bfe22.0308191528.374d2add@posting.google.com... > Hi, > I have a FSM to incorporate with some input signals. Unfortunately, > one of input signal might toggle and back to its original state within > ONE fpga clock interval. As a consequence, FSM failed to read the > signal changes. > So anyone of you know how to do this in synchronous state machine > rather than increase the fpga clock frequency? Thanks !!
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