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
In article <an3n9g$annhj$1@ID-84877.news.dfncis.de>, Falk Brunner <Falk.Brunner@gmx.de> wrote: >I did this some time ago and got ~7 ns cycle time. See timing analyzer copy >below. It uses a BRAM in 4kx1 mode. >Still 2ns missing for my planned 200 Mhz signal generator :-( Yeup, sounds about right. Thats what I seemed to get when I was doing my AES core, where I had pitch-matched registers before and not very far after the memory. Why not use an XC2S-E? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 47551
Jan,
pardon my ignorance but why couldn't you just write:
module foo(..., ...); // top level module, to be synthesized
wire rst_async; // juts a wire should be enough, shouldn't it ???
STARTUP_VIRTEX2_GSR startup(rst_async);
always @(posedge clk or posedge rst_async)
if (rst_async)
ff <= 0; // or 1, as appropriate
else
ff <= ...;
endmodule
In your testbench you would simply say:
initial
begin
force u0.reset_async = 1;
#100;
force u0.reset_async = 0;
end
(assuming your top level instance is u0 ...)
Wouldn't this do the job ?
Regards,
rudi
----------------------------------------------
www.asics.ws - Solutions for your ASIC needs -
"Jan Gray" <jsgray@acm.org> wrote in message news:<an3egi$r64$1@nntp9.atl.mindspring.net>...
> [[[Before you reply to this message, please consider the five requirements
> 1-5 below carefully. Note, I am *not* asking the standard tired questions
> about the internal GSR net vs. explicitly routed reset nets.]]]
>
> VHDL users have all the luck.
>
> Reprising this thread from 1999,
> http://groups.google.com/groups?threadm=FIw2p8.BGz%40world.std.com&rnum=1
>
> Like Joseph Allen, I wish to satisfy the following five requirements.
>
> 1. Widespread use of 0-cost GSR net to asynchronously reset or present the
> myriad FFs in my design;
>
> 2. A carefully selected subset of FFs also receive an explicit, routed,
> synchronous reset/preset signal to safely startup the key FFs in the design,
> regardless of GSR skew (but nevermind, this issue is not germane to the
> present discussion);
>
> 3. For simulation, a Verilog test bench that manages to assert and then
> deassert GSR so as to reset/preset all FFs in the design;
>
> 4. A Verilog top level design module that does *not* have an explicit reset
> net input signal (e.g. realized design will not have a reset input pin); and
>
> 5. Can write async reset/preset register semantics throughout my design,
> e.g.
> always @(posedge clk or posedge rst_async)
> if (rst_async)
> ff <= 0; // or 1;
> else
> ff <= ...;
>
> Now, were it not for requirement #4 (no reset input pin), I could simply
> write:
>
> module foo_tb(); // testbench, not synthesized
> reg rst_async;
> ... rst_async = 1; #100; rst_async = 0; ...
> foo myfoo(..., rst_async, ...);
> endmodule
>
> module foo(..., rst_async, ...); // top level module, to be synthesized
> ... input rst_async; ...
> STARTUP_VIRTEX2_GSR startup(rst_async); // NOTE1
> always @(posedge clk or posedge rst_async)
> if (rst_async)
> ff <= 0; // or 1, as appropriate
> else
> ff <= ...;
> ...
> endmodule
>
> NOTE1: Without this explicit "startup" block, Synplicity seems to route
> rst_async through programmable interconnect anyway; *with* this startup
> block, Synplicity seems to route it through the dedicated GSR net.
>
> But, requirement #4 above precludes module foo() above from receiving an
> explicit rst_async input pin.
>
> Instead, for the purposes of Verilog simulation and synthesis, it must pull
> rst_async, a.k.a. GSR, from "thin air". Were I using VHDL, I could simply
> instantiate a ROC and map rst_async to is O output port. But I'm using
> Verilog.
>
> For some reason, ROC is not and never has been provided in the Verilog
> unisim library, which is puzzling, because it seems just as necessary and
> useful there as it is in VHDL. Ditto for TOC.
>
> Just as Joseph Allen wrote three years ago, the only workable solution seems
> to burn an I/O for an unwanted reset input.
>
> ----- ASIDE ----
> Here is a famous non-solution. Even though it is the year 2002, the Xilinx
> Synthesis and Simulation Guide, for ISE 5.1i, p.6-67, still recommends the
> following crock:
>
> "module my_counter (CLK, D, Q, COUT);
> input CLK, D;
> output Q;
> output [3:0] COUT;
> wire GSR;
> reg [3:0] COUT;
> always @(posedge GSR or posedge CLK) begin
> if (GSR == 1'b1)
> COUT = 4'h0;
> else
> COUT = COUT + 1'b1;
> end
> ...
> endmodule"
>
> "Since GSR is declared as a floating wire and is not in the port list, the
> synthesis tool optimizes the GSR signal out of the design. GSR is replaced
> later by the implementation software for all post-implementation simulation
> netlists."
>
>
> Now this is an unacceptable non-solution because a) synthesis tools properly
> generate copious warnings on GSR not being driven -- and copious warnings
> are a sure sign of sloppy and unprofessional work.
>
> It is also unacceptable because b) it does not provide a way to synthesize
> an async preset FF (FDP). If you write
> if (GSR == 1'b1)
> COUT <= 4'b1111;
> ...
> you don't get four FDPs, you get an "undriven net" warning and four FDCs.
> (The back-and-forth between Allen and the gentleman from Xilinx in the above
> thread culminates in the *unbelievable* straight-faced proposal that we
> achieve the same effect as FDPs by settling for FDCs and then adding
> inverters on both their D inputs and their Q outputs. Read it and see for
> yourself.)
> ----- -----
>
> Now then, returning to the subject of this piece, VHDL users with similar
> needs do not appear to be in this quandary, because they have the ROC
> primitive, which lets you "get at" the GSR net for the purposes of
> simulating and synthesizing async reset/preset flip-flops.
>
> If the *Verilog* unisim library provided an ROC primitive, and if the
> various synthesis tools knew about it, I could simply write
> wire rst_async;
> ROC roc(.O(rst_async));
> in my top level design module and be done with it. (The VHDL ROC simulation
> model internally asserts GSR for 100 ns and is presumably optimized away by
> the synthesizer.)
>
> But sans support for Verilog ROC, I can't see away to achieve my five
> requirements stated above.
>
> Do any Xilinx Verilog designers out there know of any way to achieve 1-5?
>
> Thanks so much,
> Jan Gray, Gray Research LLC
Article: 47552I think product availability for new product introductions is an excellent topic for discussion. Often new semiconductor technology can be the vehicle for system companies to create new products with competitive and differentiating advantages. The downside is the possibility that the new semiconductor technology will not be available when committed. Altera is conscious of this issue and has done what it can to reduce the risk of product delays. The first thing that we did was add the product availability schedule to our web site so customers can get the rollout schedule for Stratix at anytime: http://www.altera.com/products/devices/stratix/overview/stx-overview.html. Second, we are more conservative with our shipment dates to give time to fix any problems if they arise with the new silicon. With Stratix, things have gone very well and we have been able to beat the published schedule for most of the devices. By the end of next week we will have sampled 5 members from the Stratix family: 1S10, 1S20, 1S25, 1S40 and 1S80. Additionally, we have pulled in the availability of the fastest speed grade devices, which are available now, and we pulled in the transition from ES to production, which will be next week for the 1S25. We will not be able to always beat our schedules, but as a rule of thumb we should always meet our published schedule. As for Cyclone, we feel very confident that it will roll-out on time. We are using the same proven process that is being used for Stratix and for the 2A70 in the APEX II family -- a process that has been in production for almost a year. The die size for Cyclone devices are quite small and there is no new exotic technology incorporated. The schedules have not been published to our web site yet, but we plan to do that in the next 2 weeks. Currently, we expect to start shipping the 1C20 in January and 1C6 in February. The remaining 2 devices will be available in April. I hope this is useful. Thanks, Steve MensorArticle: 47553
Falk Brunner wrote: > Still 2ns missing for my planned 200 Mhz signal generator :-( Ray Andraka's mentioned interleaving memories before. For a signal generator where you're effectively working as a ROM, could you take advantage of the dual-port nature of the BRAM and interleave two outputs from the same BRAM? Just another approach.Article: 47554
In article <3D95F2C7.99B573D9@mail.com>, John_H <johnhandwork@mail.com> wrote: >Falk Brunner wrote: >Ray Andraka's mentioned interleaving memories before. For a signal generator >where you're effectively working as a ROM, could you take advantage of the >dual-port nature of the BRAM and interleave two outputs from the same BRAM? > >Just another approach. Especially since you could use a 1/2 speed clock from the DLL, and have one of the blockRam ports use negative edge clocking. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 47555
"Rudolf Usselmann" <russelmann@hotmail.com> wrote > ... why couldn't you just write: > > module foo(..., ...); // top level module, to be synthesized > > wire rst_async; // juts a wire should be enough, shouldn't it ??? ... That's exactly what Xilinx advocates in the latest Synthesis and Sim Guide, p.6-67. > > "Since GSR is declared as a floating wire and is not in the port list, the > > synthesis tool optimizes the GSR signal out of the design. GSR is replaced > > later by the implementation software for all post-implementation simulation > > netlists." But: > > Now this is an unacceptable non-solution because a) synthesis tools properly > > generate copious warnings on GSR not being driven -- and copious warnings > > are a sure sign of sloppy and unprofessional work. > > > > It is also unacceptable because b) it does not provide a way to synthesize > > an async preset FF (FDP). If you write > > if (GSR == 1'b1) > > COUT <= 4'b1111; > > ... > > you don't get four FDPs, you get an "undriven net" warning, and four FDCs. Thanks, but I'm looking for something better, like VHDL unisim's ROC. Jan Gray, Gray Research LLCArticle: 47556
I need to communicate FPGA with PC. PC transfer the testbench to FPGA. FPGA response with the processing result to PC. I can choose PC ISA or PCI interface. But I don't sure the I/O pins on PC ISA or PCI slot can connect to FPGA without adding protection circuit machinism between them. IF I do connection between FPGA and PC. Does any damage be caused accidently. What is the safe interface FPGA device and PC slot?Article: 47557
Hi,
I did a couple of ISA boards using Xilinx 4000 series, without any problem,
there are a few important issues that you have to think about:
- You sould buffer all the ISA signals into the FPGA as soon as possible
- You can not load most of the ISA signals with more than a couple of TTL
loads.
- The 8 bits interface of ISA is really easy to work with but slow
- The 16 bits is litle bit more difficult, but gives you a lot more
options, but varies from computer to computer.
Don't worry about damaging the ISA, it is a pretty robust interface and if you
mase sure that all your signals are defined correctly (input, output, or IO) and
only send data when you have "permision" to, you will be fine.
Just follow the ISA standard and you will see it is one of the easiest
interfaces to work with, and you do not need a hih speed FPGA to do the job,
almost any FPGA can handle ISA communication.
I havn't done any FPGAs for PCI, it is ofcource much more complicated, and the
only board I designed for PCI, I used a PCI chip to make my life easier and
instead of debugging PCI problems, I could concentrate my time on the actual
design of my FPGA (with SDRAM, FIFO and a lot of high speed IO).
just my 2c,
/Farhad
m8931612@student.nsysu.edu.tw (Ru-Chin Tsai) wrote:
>I need to communicate FPGA with PC. PC transfer the testbench to FPGA.
>FPGA response with the processing result to PC. I can choose PC ISA or
>PCI interface. But I don't sure the I/O pins on PC ISA or PCI slot can
>connect to FPGA without adding protection circuit machinism between
>them. IF I do connection between FPGA and PC. Does any damage be
>caused accidently. What is the safe interface FPGA device and PC slot?
Article: 47558Jan, I did not see what Xilinx recommends, BUT according to your description, they omit the "STARTUP" block, which as you suggest will result in warnings and bad logic. What I suggest is to leave the "STARTUP" block but to not make that net (rst_async) an input to your top level module (declare it as a wire). Look at my original suggestion again ... Best Reards, rudi ---------------------------------------------- www.asics.ws - Solutions for your ASIC needs - "Jan Gray" <jsgray@acm.org> wrote in message news:<an4u8l$3dc$1@slb4.atl.mindspring.net>... > "Rudolf Usselmann" <russelmann@hotmail.com> wrote > > ... why couldn't you just write: > > > > module foo(..., ...); // top level module, to be synthesized > > > > wire rst_async; // juts a wire should be enough, shouldn't it ??? > ... > > That's exactly what Xilinx advocates in the latest Synthesis and Sim Guide, > p.6-67. > > > > "Since GSR is declared as a floating wire and is not in the port list, > the > > > synthesis tool optimizes the GSR signal out of the design. GSR is > replaced > > > later by the implementation software for all post-implementation > simulation > > > netlists." > > But: > > > > Now this is an unacceptable non-solution because a) synthesis tools > properly > > > generate copious warnings on GSR not being driven -- and copious > warnings > > > are a sure sign of sloppy and unprofessional work. > > > > > > It is also unacceptable because b) it does not provide a way to > synthesize > > > an async preset FF (FDP). If you write > > > if (GSR == 1'b1) > > > COUT <= 4'b1111; > > > ... > > > you don't get four FDPs, you get an "undriven net" warning, and four > FDCs. > > Thanks, but I'm looking for something better, like VHDL unisim's ROC. > > Jan Gray, Gray Research LLCArticle: 47559
The hardware specs are more than adequate for compilation. There is something specific in this design that is triggering this message. You should use mysupport.altera.com to report this error, so as to obtain a prompt resolution. - DS "Michael Tornow" <turmick@gmx.net> wrote in message news:Xns929664D94DC2Bmichaeltornowgmxnet@130.133.1.4... > Sometimes I get an error box "Full compilation was cancelled due to an > error" while compiling a design written in vhdl with Quartus 2 v2.1 (appers > on lower version aswell), but there is no error in the Message window. > It appears during the logic synthesizer is running. > I have checked this vhdl code with Leonardo Spectrum too. No errors were > found. But aslong I use LPM-functions with black boxes Quartus is running > the logic synthesizer aswell. > I'm compiling designs for 20K1500E and ARM-based Excalibur EPXA10. > For compilation I use an P4 with 1GB RAM so hardware shouldn'd be the > Problem, am I rigth? > Does anyone have an idea? > > thanks > > Michael TornowArticle: 47560
"Rudolf Usselmann" <russelmann@hotmail.com> wrote... > What I suggest is to leave the "STARTUP" block but to not make > that net (rst_async) an input to your top level module (declare > it as a wire). > > Look at my original suggestion again ... Thanks, but it doesn't help. Since the .GSR() port on the STARTUP* is an input port, that's just one more port that is driven by an undriven net, and hence one more warning. Also, still doesn't synthesize FDP (async preset FFs) properly. Since my last posting, at least for Synplicity Verilog, I have found something that does work, at the cost of just one warning in the top-level design module: wire rst_async /* synthesis syn_keep=1 */; /* no STARTUP_VIRTEX* required or desired */ The one warning is: *Input rst_async to this expression [keepbuf] has undriven bits which are being tied to 0 - a simulation mismatch is possible There are no further warnings per-use of rst_async, and I assume I can pass this rst_async to sub-modules explicitly, and FDPs *are* inferred as desired, and this satisfies my requirements 1-5 stated above. Not bad -- but a Verilog unisim ROC model would still be cleaner. Jan Gray, Gray Research LLCArticle: 47561
Check out www.opencores.org for both a cpu that will fit in to a fpga and also USB 2.0 and 1.1 IP Cores. Everything available for FREE download ! Cheers, rudi ---------------------------------------------- www.asics.ws - Solutions for your ASIC needs - steen@tech-forge.com (Steen Larsen) wrote in message news:<3e8d96d6.0209260854.6d043987@posting.google.com>... > You might also look at http://www.tech-forge.com for a PCI interface > option using Altera parts. > > For a USB option there was a general purpose IO USB1.0 solution kit > advertized in Circuit Cellar (www.circuitcellar.com) for about $50. > However then you need to interface the FPGA to it and suffer the lower > bandwidth (<12MHz) of USB1.0. USB2.0 supports up to 480MHz, but I > have not seen any FPGA kits using it. Another option is to put USB IP > in your FPGA, possibly using something like www.opencores.org. > > Best luck, > -Steen > > newb <n/a@ee.net> wrote in message news:<ee791fd.-1@WebX.sUN8CHnE>... > > Hello, > > > > I am interested in integrating a virtual cpu that can take instructions from a pc and then compute them within the fpga, then return the computed result back to the computer. I would like to know if anyone could suggest a fpga evaluation kit that would be ideal for this situation. Thank you.Article: 47562
There is a FREE ATA/ATAPI controller available for download from www.opencores.org. Regards, rudi ---------------------------------------------- www.asics.ws - Solutions for your ASIC needs - Brijesh <brijesh_spamNot@vt.edu> wrote in message news:<c4tk9.101540$TX5.4114488@news1.east.cox.net>... > hi, > I need to read/write to hard disk using FPGA, consenquently developing IDE core. > But I have not been able to find any VHDL/verilog simulation models for hard disk or even just the ATA interface. > I need the models to test the interface only. Even only the PIO mode will do. > Are there any such models? > > Thanks > brijeshArticle: 47563
I am one of the contributors to OpenCores. The goal here is to create a large and mature IP library that can be used by commercial users. The hope is that we will get cheaper and/or better quality hardware faster that we might otherwise. I have worked for several commercial companies where the "next generation" product was delayed by 1-2 years to "milk" the previous product and extend it's live.That kind of strategies make me as an engineer and consumer very angry. Another item that disturbs me is the artificially blown up "R&D" budgets at some companies. These R&D budgets are financed from the hardware sale. Some of those R&D departments are a joke ! Companies like IBM seem to have R&D departments that every couple of months come up with something new and cool they have developed. 80% of other companies with huge R&D devisions, just burn the money without producing anything. How do we make money ? As somebody already mentioned, providing the IP core is just a small part of the job. You will find IP cores that are quite decent designs and work of professionals and you will also find projects that have not been completed in the last few years. To take an IP core from it's source form and put it in to an ASIC is a lot of work. My company is trying to adopt the model that seems to work for software companies (like RedHet for example): Get the core for free, but please buy support if you are going to use it. And no, I will not *force* a commercial client to buy support or pay me. In the past OpenCores has been supported in one way or another by many different sponsors. There is even a sponsors page up. One company (Flextronics Semiconductor of Israel) even payed some of us to develop a few cores that they wanted for one of their projects. I think that was very nice of them. They got what they needed, the community got something for free, and the developers where able to pay their bills ! The best thing about the deal with Flextronics was that the cores that where developed in that deal, where very mature and complete implementations. They where complete with all test benches, documentation and where synthesized and tried in silicon. What else could one dream of ? Why didn't you guys CC this to the oOpenCores mailing list ?! Best Regards, rudi (Will write IP cores for food ;*) ---------------------------------------------- www.asics.ws - Solutions for your ASIC needs - Colin Marquardt <c.marquardt@alcatel.de> wrote in message news:<k8z7khq6tj7.fsf@alcatel.de>... > hmurray@suespammers.org (Hal Murray) writes: > > >>While I'm a big "information needs to be free" kind of guy, it seems > >>kind of strange to me that the primary contributers are individuals, > >>and the main beneficiaries (financially) are business entities. > >>Aren't these kinds of projects usually handled under a "use limited to > >>not for profit" arrangement? Kind of like shareware WS-FTP, if you're > >>using it at school go ahead, but if you're making money using it, you > >>shell out your $30. Otherwise all that we've accomplished is reducing > >>corporate NRE at engineers' expense. > > > > I'm not sure Opencores is over the hump yet. For small things > > it's as easy/cheap to reinvent the solution as it is to integrate > > some external package into your project. For large complicated > > cores/packages it really helps to have lots of users helping to find > > (and fix) all the bugs. > > As was already hinted either here or some other EDA newsgroup some while > ago, a big electronics company headquartered in Singapore is/was employing > people to contribute to opencores.org. If details can be made public, I > would like to know about them. > > Cheers, > ColinArticle: 47564
Hi, I read some of the previous posts of the topic, but wanted to get the current opinion of the group. I want to get started with FPGA and microcontroller programming. I purchased a CPS144 PICALL 3.42 kit from Amazon Electronics, and some 16F84 chips. Along with the free picasm software, I think I am reasonably set there. However, on the FPGA side, I am undecided as to what would be a good starter kit. I have been playing with GNU Electric, which is a VHDL simulator and compiler. I see that Altera has a ByteBlaster programming cable that is reasonably flexible. I have also seen others recommend Altera FLEX 6K series of chips. Is this a reasonable way to go? I am not sure what to look for really, having taken a design class, but being pretty much a complete newbie to the FPGA market otherwise. Some of the kits I have run across: http://www.al-williams.com/pbx84.htm (Xilinx) http://www.hvwtech.com/intro-fpga.htm (Altera Max) I am also looking into homebrew PCB layout. Press-N-Peel seems like a good solution. Any other suggestions? Thanks for any insight.Article: 47565
Hello Prashant, "Prashant" <prashantj@usa.net> a écrit dans le message news: ea62e09.0209241203.7d9e7e09@posting.google.com... > Hi, > > The device on my the Altera board connects to external RAMs and other > devices. > > If all unused pins were left as "outputs driving gnd", would it be a > problem if an output pin of another device on the board connected to > an APEX pin, which is also set as an output (and driving gnd) ? Since > I'm not using the external RAM, I would consider such a pin as unused. > > I'm not sure if that would be a problem or not. If it is a problem > then I will have to go find all such pins and assign them as inputs > tristated. If you've something connected to the pin, it will be certainly a problem. You can even destroy the circuit connected on some board. (I don't have the DSP board from Altera...) You can leave all unsed pins as tri-stated without problem but the FPGA circuit will drive a little more current if no pull-up or pull-down resistor are present on these pins. Cédric GaudinArticle: 47566
Hi, How do I design a multiplier that outputs a signal 3x that of the input clock signal? Background: The clock signal is 100 Mhz and the design is to be downloaded to an FPGA. Thanks. Dennis (dennislwm@hotmail.com) PS Reply to .com (not .net)Article: 47567
Hello all, I use the Xilinx Chipscope 3.3 for monitoring the signals of my FPGAs. In this version the ILA core generated has too many logic levels in the trigger part thus the timing is not so good, is the same in the new version of the Chipscope or are there any changes in the cores so to succeed better timing without the need of floorplaning e.t.c? Greetings , HarrisArticle: 47568
Hi, Can anyone Please help me to instantiate embedded memory blocks of altera devices/FPGAs in my design? I understand for Xilinx FPGAs that can done through "CoreGen" utility. How to do the same for Altera FPGAs? Sudip Saha sudip.saha@philips.comArticle: 47569
On Fri, 27 Sep 2002 22:24:44 -0700, "Jan Gray" <jsgray@acm.org> wrote: >[[[Before you reply to this message, please consider the five requirements >1-5 below carefully. Note, I am *not* asking the standard tired questions >about the internal GSR net vs. explicitly routed reset nets.]]] > >VHDL users have all the luck. > >Reprising this thread from 1999, >http://groups.google.com/groups?threadm=FIw2p8.BGz%40world.std.com&rnum=1 > >Like Joseph Allen, I wish to satisfy the following five requirements. > >1. Widespread use of 0-cost GSR net to asynchronously reset or present the >myriad FFs in my design; > >2. A carefully selected subset of FFs also receive an explicit, routed, >synchronous reset/preset signal to safely startup the key FFs in the design, >regardless of GSR skew (but nevermind, this issue is not germane to the >present discussion); > >3. For simulation, a Verilog test bench that manages to assert and then >deassert GSR so as to reset/preset all FFs in the design; > >4. A Verilog top level design module that does *not* have an explicit reset >net input signal (e.g. realized design will not have a reset input pin); and > >5. Can write async reset/preset register semantics throughout my design, >e.g. > always @(posedge clk or posedge rst_async) > if (rst_async) > ff <= 0; // or 1; > else > ff <= ...; > >Now, were it not for requirement #4 (no reset input pin), I could simply >write: > >module foo_tb(); // testbench, not synthesized > reg rst_async; > ... rst_async = 1; #100; rst_async = 0; ... > foo myfoo(..., rst_async, ...); >endmodule > >module foo(..., rst_async, ...); // top level module, to be synthesized > ... input rst_async; ... > STARTUP_VIRTEX2_GSR startup(rst_async); // NOTE1 > always @(posedge clk or posedge rst_async) > if (rst_async) > ff <= 0; // or 1, as appropriate > else > ff <= ...; > ... >endmodule > >NOTE1: Without this explicit "startup" block, Synplicity seems to route >rst_async through programmable interconnect anyway; *with* this startup >block, Synplicity seems to route it through the dedicated GSR net. > >But, requirement #4 above precludes module foo() above from receiving an >explicit rst_async input pin. > >Instead, for the purposes of Verilog simulation and synthesis, it must pull >rst_async, a.k.a. GSR, from "thin air". Were I using VHDL, I could simply >instantiate a ROC and map rst_async to is O output port. But I'm using >Verilog. > >For some reason, ROC is not and never has been provided in the Verilog >unisim library, which is puzzling, because it seems just as necessary and >useful there as it is in VHDL. Ditto for TOC. > >Just as Joseph Allen wrote three years ago, the only workable solution seems >to burn an I/O for an unwanted reset input. > >----- ASIDE ---- >Here is a famous non-solution. Even though it is the year 2002, the Xilinx >Synthesis and Simulation Guide, for ISE 5.1i, p.6-67, still recommends the >following crock: > >"module my_counter (CLK, D, Q, COUT); >input CLK, D; >output Q; >output [3:0] COUT; >wire GSR; >reg [3:0] COUT; >always @(posedge GSR or posedge CLK) begin > if (GSR == 1'b1) > COUT = 4'h0; > else > COUT = COUT + 1'b1; >end >... >endmodule" > >"Since GSR is declared as a floating wire and is not in the port list, the >synthesis tool optimizes the GSR signal out of the design. GSR is replaced >later by the implementation software for all post-implementation simulation >netlists." > > >Now this is an unacceptable non-solution because a) synthesis tools properly >generate copious warnings on GSR not being driven -- and copious warnings >are a sure sign of sloppy and unprofessional work. > >It is also unacceptable because b) it does not provide a way to synthesize >an async preset FF (FDP). If you write > if (GSR == 1'b1) > COUT <= 4'b1111; > ... >you don't get four FDPs, you get an "undriven net" warning and four FDCs. >(The back-and-forth between Allen and the gentleman from Xilinx in the above >thread culminates in the *unbelievable* straight-faced proposal that we >achieve the same effect as FDPs by settling for FDCs and then adding >inverters on both their D inputs and their Q outputs. Read it and see for >yourself.) >----- ----- > >Now then, returning to the subject of this piece, VHDL users with similar >needs do not appear to be in this quandary, because they have the ROC >primitive, which lets you "get at" the GSR net for the purposes of >simulating and synthesizing async reset/preset flip-flops. > >If the *Verilog* unisim library provided an ROC primitive, and if the >various synthesis tools knew about it, I could simply write > wire rst_async; > ROC roc(.O(rst_async)); >in my top level design module and be done with it. (The VHDL ROC simulation >model internally asserts GSR for 100 ns and is presumably optimized away by >the synthesizer.) > >But sans support for Verilog ROC, I can't see away to achieve my five >requirements stated above. > >Do any Xilinx Verilog designers out there know of any way to achieve 1-5? > >Thanks so much, >Jan Gray, Gray Research LLC Hi Jan, Is there any reason why you can't create your own ROC in Verilog, and pretend it was in unisim all along? I imagine that the distinction between VHDL and Verilog disappears early in the compilation phase of the synthesiser (before it gets up to identifying special components like ROC), so this trick might just work. (Fingers crossed.) Regards, Allan.Article: 47570
"Jan Gray" <jsgray@acm.org> wrote in message news:<an5u2f$ntn$1@slb6.atl.mindspring.net>... > "Rudolf Usselmann" <russelmann@hotmail.com> wrote... > > What I suggest is to leave the "STARTUP" block but to not make > > that net (rst_async) an input to your top level module (declare > > it as a wire). > > > > Look at my original suggestion again ... > > Thanks, but it doesn't help. Since the .GSR() port on the STARTUP* is an > input port, that's just one more port that is driven by an undriven net, and > hence one more warning. Also, still doesn't synthesize FDP (async preset > FFs) properly. Hmm, I haven't tried it, but my STARTUP blocks have "// synthesis syn_black_box .noprune=1" therefore should not be removed. Which I would guess is similar to the "syn_keep" you describe below ? I wonder, why do they declare it an input and not an output ?! (or even inout ...) Anyway, very interesting ! Cheers, rudi ---------------------------------------------- www.asics.ws - Solutions for your ASIC needs - > Since my last posting, at least for Synplicity Verilog, I have found > something that does work, at the cost of just one warning in the top-level > design module: > > wire rst_async /* synthesis syn_keep=1 */; > /* no STARTUP_VIRTEX* required or desired */ > > The one warning is: > *Input rst_async to this expression [keepbuf] has undriven bits which are > being tied to 0 - a simulation mismatch is possible > > There are no further warnings per-use of rst_async, and > I assume I can pass this rst_async to sub-modules explicitly, and > FDPs *are* inferred as desired, and > this satisfies my requirements 1-5 stated above. > > Not bad -- but a Verilog unisim ROC model would still be cleaner. > > Jan Gray, Gray Research LLCArticle: 47571
Every Xilinx Virtex-II device has several internal Digital Clock Manager circuits that do this ( and many other useful things) for free. The incoming clock needs to be free-running (never stopping). Peter Alfke, Xilinx Applications ================================== Dennis wrote: > Hi, > > How do I design a multiplier that outputs a signal 3x > that of the input clock signal? > > Background: > The clock signal is 100 Mhz and the design is to be > downloaded to an FPGA. > > Thanks. > > Dennis (dennislwm@hotmail.com) > > PS Reply to .com (not .net)Article: 47572
"Marty" <martin.quenneville@rd-tech.com> wrote in message news:<V3lk9.13303$H67.63152@tor-nn1.netcom.ca>... > Dan, > > We use a development board from Insight Electronics. The board is available > for XC2VP4/P7 Virtex II-pro devices. You can purchase the board online on > their web site : http://www.insight-electronics.com. Did you get a bitfile that supports the SDRAM on this Insight board ? only SRAM is standardly supported, but that is too small to do practical Linux work. We also bought the P160 communications extention board (Ethernet, PS2, serial, ...). > Marty. > > "Dan" <hombecker1962@hotmail.com> wrote in message > news:f6989659.0209242140.845a696@posting.google.com... > > Is anyone aware of current development boards and software packages > > available for the Virtex II Pro series with the embedded power pc > > processor (namely one or two). I'm not having much luck finding them. > > I know it's a very recent product, and I think this is one of my > > problems. A Linux port was posted some time ago by Peter 'p2' De Schrijver. It can also be found through anonymous ftp.mind.be. The ppc boot port for this board is included in the new ppcboot 1.2.0 that was released an hour ago. Peter > > Thanks, > > DanArticle: 47573
The Quartus II tool provides the Megawizard Plug In manager to configure and
integrate IP blocks with the users design. Each IP block has its own
Megawizard Plug In, which can be accessed through the Megawizard Plug In
Manager. Memories are examples of IP block. The steps to integrate IP are as
follows:
1. Open Quartus II
2. Click on Tools Megawizard Plug In Manager
3. Click on Create a new custom megafunction variation and hit Next
4. In the Available Functions list click on storage to expand the list of
storage elements available
5. Select the type of storage you need. If you are not sure of the choices
- Altsyncram is used for Stratix
- The LPM ones can be used either for specific families or all families
- Search the Quartus II online help search for "Memory" to obtain more
information on the capabilities of the different Memory functions and which
family they should be used for
6. Select the type of Output file to generate (VHDL, Verilog or AHDL)
7. Give the output file a name. (you cannot go to the next dialog without
this)
8. Make sure that the storage is selected (important) and hit Next
9. At this point you can configure the memory to your specification. (for
example the LPM_FIFO will walk you through another 6 panels. You can choose
defaults or change them according to your needs.
10. The last panel will show the list of files that are generated when you
hit Finish
The vhd file is the VHDL representation of the FIFO function. (as I
chose VHDL in step 6)
Three additional fies are generated to allow easy interfacing, with
other design entry methods. They are
The cmp file which contains the VHDL component description
The inc file is a AHDL function declaration, to call the FIFO block from
a AHDL file
The bsf file is a symbol if you want to call the FIFO block from the
Quartus II Block Editor file
11. Finally you will need to call this FIFO block from your design file. If
you are using a EDA synthesis tool, Search the Quartus II Online help for
"Black Boxing". There are several choices. Some of them that are useful are:
- "Creating & Instantiating a VHDL Function for Use with the Synplify
Software"
- "Creating & Instantiating a Verilog HDL Function for Use with the Synplify
Software"
- See
http://www.altera.com/support/software/nativelink/synthesis/syn-index.html
for more information
12. Once you have the FIFO block instantiated as a black box it is a regular
flow, for synthesis and behavioral simulation.
Additional tips:
13. If the memory you choose can be initialized at power up, you should
specify the memory initialization file (.mif) when configuring it in the
Megawizard. The mif files can be created using the Memory Editor that is a
part of Quartus II.
14. If you have forgotten a setting when configuring the memory block you
can edit the file from the Megawizard Plug In manager. In the first panel
select Edit a existing custom megafunction variation and continue.
- DS
"Sudip Saha" <sudip.saha@philips.com> wrote in message
news:ee79446.-1@WebX.sUN8CHnE...
> Hi,
> Can anyone Please help me to instantiate embedded memory blocks of altera
devices/FPGAs in my design? I understand for Xilinx FPGAs that can done
through "CoreGen" utility. How to do the same for Altera FPGAs?
>
> Sudip Saha
> sudip.saha@philips.com
Article: 47574Hal Murray wrote: >>Interesting point, but very wrong. ISA may not be around long in >>standard PCs, but it is still very much in use in embedded computers and >>PC/104 systems. PC/104 is still on the upswing and will continue to be >>a viable market for many years to come. > > > I thought PC/104 was PCI rather than ISA. > > What am I missing? > > PC/104 is based on ISA but there is another version called PC/104 Plus which uses PCI as a basis. I am using PC/104 in one of my designs and it works great. I didn't even had to worry to much about board layout and FPGA protection. I had though to convert some of the signals getting into the FPGA from 5V -> 3.3V since the VirtexE family has trouble with 5V IOs. (Actually, it accepts 5V inputs in certain conditions but you need to be careful). VirtexII is not 5V tolerant. Dali
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