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 Spike,
I own the Insight Electronics PCI card mentioned in the article, but it
has been discontinued some time ago and replaced with a newer version.
http://www.insight.na.memec.com/Memec/iplanet/link1/SpartanII200PCI.pdf
You might also want to consider Avnet Spartan-3 evaluation card if you
don't mind the higher price and a minor violation of the PCI
specification (i.e., voltage converters between the Spartan-3 and the
PCI card edge.).
http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D7816%2526CCD%253DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID%253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html
Spike, have you considered what to do with the PCI interface
once you purchase the card?
I am planning to release a PCI IP core I developed around end of May.
It will be available for $100 as long as the user agrees to use it for
non-commercial, non-profit, non-academic research, and personal
purposes.
The licensee will need a PayPal account to send the payment, and a Yahoo
account to download the PCI IP core.
I was originally planning to make the PCI IP core was going to be
available only to people residing in the United States who have a valid
PayPal account, but I changed my mind, and it will now be available to
people who have a valid PayPal account living overseas as well.
Here is what my PCI IP core will look like:
* PCI Local Bus Revision 2.2 compliant.
* Burst initiator/target access support.
* 6 Base Address Register (BAR) and Expansion ROM BAR support.
* Meets 33MHz PCI timings with Spartan-II-5
* General purpose PCI testbench comes with a PCI arbiter, PCI host
bridge emulator, and PCI target device to allow the user to quickly
debug their design.
* The PCI IP core supplied in NGO netlist format (Xilinx's proprietary
netlist format.).
* Nominally supports Xilinx Virtex, Spartan-II, or newer FPGAs.
* Constraint file supplied for Spartan-II PQ208 and FG456 package,
Virtex-E XCV300E BG432 package, Insight Electronics Spartan-II 150 PCI
card, and Spartan-II 200 PCI card.
* Comes with three reference designs (Two similar target only designs
and one target/initiator design.).
* Fully supports Verilog (Reference designs and the PCI testbench are
written in Verilog.).
* Limited VHDL support (No reference designs and PCI testbench. Verilog
version of the reference designs and PCI testbench will eventually be
ported to VHDL.).
* Supports ISE WebPACK 3.2 through ISE WebPACK 6.2 (The use of ISE
WebPACK 5.1 or later is strongly recommended.).
Kevin Brace
P.S. Remove the weird numbers from the E-mail address when contacting
me.
Spike wrote:
>
> Hi again!
>
> I just looked at this: http://www.xilinx.com/xcell/xl38/xcell38_13.pdf, but
> I'm not sure where I can buy it and whether or not it fulfills me needs...
> Has any one tried it?
>
> //SPike
Article: 67801The Stratix logic cell contains one LUT and one register. The register can be fed either from the LUT output or directly. Probably the best diagram of the logic cell internals is on pg 2-7 of http://www.altera.com/literature/hb/stx/ch_2_vol_1.pdf. -- Pete maxlim79@hotmail.com (Maxlim) wrote in message news:<a6140565.0403190246.131b49f1@posting.google.com>... > In Altera Quartus compilation report of Stratix device, it shows the > usage of logic cells, registers, memory bits, DSP elements, and etc. > From Stratix device documentation, I read about logic cells, memory > bits. ... in Stratix architecture except the registers. Just saw some > input/output register in the DSP blocks. > > Can somebody explain to me where is the registers showed by the > compilation report in Stratix architecture?Article: 67802
A latch is an asynchronous circuit element. Many ASIC designs are done using
strictly synchronous elements in order to allow the use of full internal scan
testing. Scan testing relies on the circuit under test being a purely
synchronous structure, so any latches in the design won't be part of a
"standard" scan chain, resulting in test coverage holes.
This design-for-test practise obviously does not apply to FPGA's, so if a latch
is what you need, infer away. Just be careful that you do not infer a latch
where you intend to infer a flip flop.
Mark
arvind wrote:
> Hi all,
> So many Books and articles on Web told me to Avoid Infer
> latches in design, But Thay did't give the Proper reason behind this
> and i did't convince. So can anybody give me the Short and Sweet
> answer about my Question "why it is recommended to avoid latches in
> Digital Designs?"
>
> Thanks for any Reply.
>
> Best Regards
> Arvind Singh Tomar.
Article: 67803
Sounds like you are trying to do 18x18 unsigned multiplication. The
multipliers are 18x18 SIGNED only. For unsigned, you are constrained
to 17x17 and you have to tie the msbs to '0'.
David Roberts wrote:
> Hi,
>
> Can anyone suggest how to prevent ISE from synthesising one 18x18
> multiplication to 3 multiplier blocks?
>
> Thanks,
>
> Dave.
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 67804Hi. I've got a XSA-50 and the according ps2 cable. I want to read back signals from the board into a C application, in order to draw waveforms, etc. I heard there are a few libraries arround, but couldn't "stumble" on one so far. Any ideas where I should be looking?:)Article: 67805
When they are not actively driving, and when the weak pull-up or -down option is disabled, Xilinx I/O pins draw practically no current. The spec says max 10 µA, but in reality it is far less. DC current is not your problem, capacitive load is something you should be concerned about. For those of us that grew up with TTL, it is important to remember: CMOS has no input current, and also no output offset. An unloaded output drives all the way to Vcc or to ground. Isn't that nice! Peter Alfke =============================== > From: sgarcia_castillo@hotmail.com (Sergio) > Organization: http://groups.google.com > Newsgroups: comp.arch.fpga > Date: 19 Mar 2004 06:56:54 -0800 > Subject: Re: LVTTL Spartan-3 pin input current... > > Thanks Bob, I'll be working with some parts provided by Memec, I'll > let you know how much current each pin sinks as soon as I finish the > board. I was a bit concerned since I am designing a multichannel > system, I need to implement data and address buses with 32 > Spartan-3(400). For the data bus there is no problem since while one > FPGA provides the data at the bus, the others are in high impedance; > however, the adress bus has to be listened by every FPGA (5 pins), if > the current that each pin sinks is in micro-amps levels even a normal > LVTTL source can provide enough current for all FPGAs (I was thinking > to use a CPLD to provide the address bus); nevertheless, if the > current is more than that I have other options that involve more > components in my board. Another option is to provide a CS signal for > each FPGA, then just one listener per source pin is required with 32 > tracks more. What do you think?, thanks again for your help > > SergioArticle: 67806
process(input) begin if (input='1')then output<='1'; end if; end process; Once output goes hi, it can't never go low again. arvindstomar@india.com (arvind) wrote in message news:<56147fd4.0403190344.796d99e9@posting.google.com>... > Hi all, > So many Books and articles on Web told me to Avoid Infer > latches in design, But Thay did't give the Proper reason behind this > and i did't convince. So can anybody give me the Short and Sweet > answer about my Question "why it is recommended to avoid latches in > Digital Designs?" > > Thanks for any Reply. > > Best Regards > Arvind Singh Tomar.Article: 67807
valentin tihomirov wrote: > > Thank you for the idea. But I'm missing something: UNISIM is post-synthesis > library. However, functional and post-synthesis simulations don't require > long reset. This problem is observed only in timing simulation. For timing simulation with Xilinx FPGAs, a global set/reset (GSR) is automatically asserted at the begining of simulation. The reason for this is to mimic what happens after configuration of the FPGA. One of the final stages of conifguration is the assertion of the GSR net (a dedicated wire connected to the set or reset of every FF in the FPGA) to bring the design into a known state after the completion of configuration. For timing simulation, you can think of the start of simulation as being the beginning of the assertion of the GSR net and similar as in the real FPGA, the purpose to include this in simulation is to ensure the simulation starts in that same known state as the FPGA would. The default value for this in simulation is 100 ns but that can be changed by either adding the appropriate switch to netgen or changing the appropriate property for simulation netlist generation in Project Navigator however I generally suggest to just leave it at 100 ns. Why 100 ns? 100 ns is not the actual value of the GSR pulse but was an arbitrary round number choosen so that it is easy to know when GSR ends and does not take too much simulation time away but does give a chance for all clocks and input stimulus to become stable in the simulation. The actual amount of time is dependent on many things including which device you target, whether you are using the STARTUP block or not, as well as process and environmental factors so choosing a round 100 ns number makes it easier to build your testbench knowing when that GSR pulse ends. So what does all of this mean to you? You must account for this GSR pulse in your timing simulation. You can change the duration of this but it is not suggested. You should still initialize all input stimilus and drive your clocks at time zero however I would not drive stimulus you expect to react for simulation until after the 100 ns pulse has completed. In fact, I generally recommend for functional simulation, to also hold off processing data util after 100 ns has passed so that the same testbench can be used for both functional and timing simultaion. As for the simple code snip you posted previously, I am not sure if that would do anything in a timing simulation or the chip itself for that matter. I would need to see the rest to be sure but based on what I saw, most likely what would happen if the circuit was not optimized to a 'logic 1' on that output would be that the GSR would drive that inferred FF to a 'logic 1' so that at 100 ns when you should start driving your stimulus, that register will already be a 'logic 1'. I think your test is a little too simple to try to figure out FPGA functionality or timing. You might want to try a little more substantial test where the FF is at least clocking in data to better understand how this would be inplemented. My guess at what your issue ther is that this example is so simple it is being optimized to the point that you are not seeing what you might expect. -- BrianArticle: 67808
arvind wrote:
> So can anybody give me the Short and Sweet
> answer about my Question "why it is recommended to avoid latches in
> Digital Designs?"
Because latches are incompatible with synchronous
design and automated static timing analysis.
-- Mike Treseler
Article: 67809Hi, You, or anybody else who's interested in a Virtex based PCI prototyping board, can go to: http://www.engr.sjsu.edu/crabill/projects/nxm/readme.htm http://www.engr.sjsu.edu/crabill/projects/nxm/ Download the gerber photoplots, bill of materials, and schematics. You can build some for yourself and sell the rest if you want (I don't care...) Eric Spike wrote: > > ok, I would like to make my own PCI board (a stand-alone PCI card which I > can insert in an computer with a free PCI slot). Nothing fancy just a board > that could send out I/O data or what ever. > > For this task I've heard that FPGA would be a good choice. > > I don't know how to explain it better but if I've missed something, let me > know. > > Thanks! > > //SPike > > "rickman" <spamgoeshere4@yahoo.com> skrev i meddelandet > news:405A4A18.5555C689@yahoo.com... > > Spike wrote: > > > > > > I can't say I know enough about FPGA processors to choose a good one, > that's > > > mainly why asked this question. I was hoping that you could give me some > > > advices... > > > > That will require that you explain in detail what you want to do with > > it. And be prepared for a lot of advice on what you want to do as well > > as how to do it... ;) > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67810
David Rogoff wrote: > ... > I assume the floating licenses will share across - correct? At least with Synplify, yes the floating license works with the Linux version of Synplify. In fact, it is required; at least the last time I checked, a node locked license was not available for Linux :-(Article: 67811
Hi "Current design is not a view" I get this error message when trying to running a synthesis script for an Spartan XL fpga. I have run my script several times without errors, but now i get this message each time i try to run the script, and the script stops running. I'm running my script from within the UI using the source command. I still can run the synthesis using the UI, so the error is not related to the hld code. Any sugestion what i have messed up in my setup, and what the cure is to bring my design back on track. Regards Kurt Müller DenmarkArticle: 67812
"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message news:<405a9fdf$1@news.starhub.net.sg>... > Gupta, > > Are you willing to release the source code for sasm.exe? Its already there. Click on downloads in the sidebar. Sumit > > Best Regards, > Kelvin > > > Sumit Gupta <do_not_reply_to_this_addr@yahoo.com> wrote in message > news:4ru6c.26051$nH2.4810@newssvr29.news.prodigy.com... > > I wrote a sample VC++ program to download Xilinx FPGAs via slave serial > mode > > using JTAG cable (parallel cable III). I have posted it to my website. Its > > compiled as a windows console application. I used inpout32.dll library to > > talk to parallel port of the PC. The program works on my win2K laptop. > > > > Sumit > > ----- > > http://www.c-nit.net > > > >Article: 67813
Peter Alfke wrote: > > When they are not actively driving, and when the weak pull-up or -down > option is disabled, Xilinx I/O pins draw practically no current. The spec > says max 10 µA, but in reality it is far less. DC current is not your > problem, capacitive load is something you should be concerned about. > > For those of us that grew up with TTL, it is important to remember: > CMOS has no input current, and also no output offset. An unloaded output > drives all the way to Vcc or to ground. Isn't that nice! Peter, I have always wondered about this, but never come to any conclusions. TTL circuits had a limit to the pullup voltage of about 3 volts when powered by 5 volts. That was above the 2.4 volt requirement, so it was fine. When a CMOS technology is spec'd to the same TTL standards on input and output (0.8/0.4 low, 2.0/2.4 high) do they *always* pull up to Vdd if there is no appreciable load? I never wanted to make any assumptions in case there are CMOS outputs that are *not* designed to pull up to Vdd. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67814
Hello All and particularly Justin Cowling (see excerpt below) Don't see too much here re: DSP Builder or SystemGenerator... I am trying out for the first time the DSP Builder 2.1.3 for a portion of my design. Pleased to report that installation was trouble-free, haven't yet generated any VHDL. I am comfortable with VHDL, proficient at Matlab and can do simple stuff with Simulink. I care about (1) getting the job done faster, which I'm looking forward to being better able to see what I'm doing as I go along (2) hopefully much easier to validate minor/modest functional changes. Can an enlightened person help me with the following questions : 1. In my design I extensively use true dual port RAM with different sizes on Port A and Port B. The Altera DSP Builder provides what appears to be simple dual port RAM with same size on Port A and Port B. Is there either a workaround or a subsystem model available somewhere that builds a true dual port RAM out of existing components ? For me, only one port needs write access, but both ports need read. > If you compare DSP Builder to HDL's and > you are more comfortable with HDL's, the main reasons for working with > DSP Builder will be for the verification flow. 2. I was intrigued by the SubSystemBuilder block which allows you to import existing VHDL, but it appears that I can only import VHDL entities, not the components. Aside from being a pain to draw graphically something that's already working in VHDL, I am also confused about how this fits in with verification. It would appear a big weakness to have comprehensively tested something different from what you're going to deploy. What's the intent here ? 3. It would be really neat to be able to run my existing VHDL as part of my Simulink simulation. (In fact when I first heard about DSP Builder I had the wild hope that it could convert *any* Simulink model into VHDL -- but I can appreciate the difficulty in that.) The converse however, VHDL->Simulink may be easier. I'm sure Altera has people working on it, question is how far off is this ? Thanks for any enlightenment, -rajeev- ----------------------- On Jan 31,2003 Justin Cowling wrote: http://groups.google.com/groups?q=altera+dsp+builder+group:comp.arch.fpga&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.arch.fpga&selm=316e0ba7.0301310711.4b766065%40posting.google.com&rnum=1 > Your question about the quality of these tools is a good one. The > evolution of Altera's DSP Builder has been extremely rapid over the > last two years. With the latest release of DSP Builder 2.1, major > strides have been made in overall capability and quality. These tools <...> > DSP Builder Weaknesses > - DSP Builder does have a graphical Finite State Machine, however, > many consider language based control capture significantly more > productive (assuming you know how to write HDL). > - DSP Builder only supports a sub-set of all Altera and 3rd party IP > because it requires Mathworks C models for every block. > - Currently, DSP Builder only supports VHDL. > If you compare the capabilities of DSP Builder and Simulink against > comparable tools like SPW, DSP Builder does essentially the same thing > for a fraction of the cost. If you compare DSP Builder to HDL's and > you are more comfortable with HDL's, the main reasons for working with > DSP Builder will be for the verification flow. > If you want a graphical tool for implementing DSP hardware, DSP > Builder and Simulink have leading edge capabilities and a low price. > Justin Cowling > Director IP Marketing > Altera CorpArticle: 67815
Mike Treseler wrote:
> arvind wrote:
>> So can anybody give me the Short and Sweet
>> answer about my Question "why it is recommended to avoid latches in
>> Digital Designs?"
>
> Because latches are incompatible with synchronous
> design and automated static timing analysis.
Right. Infer flip-flops instead. In Verilog:
reg foo;
always @(posedge clk) foo <= some_expression;
or the more verbose and not necessarily more useful:
reg foo;
always @(posedge clk or posedge rst) if (rst) begin
foo <= 0;
end else begin
foo <= some_expression;
end
I'll leave the VHDL versions to someone else.
My fingers get tired too quickly. ;-)
If someone wants to argue that the above is not
really inference, I would counter that since it
is not an instantiation of a primitive, it must
be inference. What other (named) categories of
resultant hardware are there in a HDL?
- Larry
Article: 67816Well,...how can we write/read data to a fast SRAM with address access time < 10ns?Article: 67817
All conventional CMOS output ( not "open collector" GTL and the almost linear LVDS) sink and source "rail-to-rail". No inherent offset voltage at zero current. Close to ground and Vcc the outputs are resistive to the first approximation. The 2.0/2.4 V and 0.4/0.8 V specs are historical baggage from the TTL days, same as inches and feet are relics from old English kings' body dimensions. Peter Alfke > From: rickman <spamgoeshere4@yahoo.com> > Reply-To: spamgoeshere4@yahoo.com > Newsgroups: comp.arch.fpga > Date: Fri, 19 Mar 2004 14:44:49 -0500 > Subject: Re: LVTTL Spartan-3 pin input current... > > Peter Alfke wrote: >> >> When they are not actively driving, and when the weak pull-up or -down >> option is disabled, Xilinx I/O pins draw practically no current. The spec >> says max 10 µA, but in reality it is far less. DC current is not your >> problem, capacitive load is something you should be concerned about. >> >> For those of us that grew up with TTL, it is important to remember: >> CMOS has no input current, and also no output offset. An unloaded output >> drives all the way to Vcc or to ground. Isn't that nice! > > Peter, > > I have always wondered about this, but never come to any conclusions. > TTL circuits had a limit to the pullup voltage of about 3 volts when > powered by 5 volts. That was above the 2.4 volt requirement, so it was > fine. > > When a CMOS technology is spec'd to the same TTL standards on input and > output (0.8/0.4 low, 2.0/2.4 high) do they *always* pull up to Vdd if > there is no appreciable load? I never wanted to make any assumptions in > case there are CMOS outputs that are *not* designed to pull up to Vdd. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67818
But, In the not-so-very-old-days where nmos transistors were cheaper (in area) and faster (in performance)than the pmos transistors, one could build an output structure that had only nmos transistors for the pullup and pulldown. Such a structure could not pull any closer than a Vt to the Vcc rail, and thus "5V all nmos" output stacks looked just like a TTL output stack, and had similar voltage levels. To tolerate very large overshoot, sometimes two nmos were used in series, and then it even looked more like TTL, with a strong pull down, and relatively weaker pull up. Austin Peter Alfke wrote: > All conventional CMOS output ( not "open collector" GTL and the almost > linear LVDS) sink and source "rail-to-rail". No inherent offset voltage at > zero current. Close to ground and Vcc the outputs are resistive to the first > approximation. > The 2.0/2.4 V and 0.4/0.8 V specs are historical baggage from the TTL days, > same as inches and feet are relics from old English kings' body dimensions. > > Peter Alfke > > >>From: rickman <spamgoeshere4@yahoo.com> >>Reply-To: spamgoeshere4@yahoo.com >>Newsgroups: comp.arch.fpga >>Date: Fri, 19 Mar 2004 14:44:49 -0500 >>Subject: Re: LVTTL Spartan-3 pin input current... >> >>Peter Alfke wrote: >> >>>When they are not actively driving, and when the weak pull-up or -down >>>option is disabled, Xilinx I/O pins draw practically no current. The spec >>>says max 10 µA, but in reality it is far less. DC current is not your >>>problem, capacitive load is something you should be concerned about. >>> >>>For those of us that grew up with TTL, it is important to remember: >>>CMOS has no input current, and also no output offset. An unloaded output >>>drives all the way to Vcc or to ground. Isn't that nice! >> >>Peter, >> >>I have always wondered about this, but never come to any conclusions. >>TTL circuits had a limit to the pullup voltage of about 3 volts when >>powered by 5 volts. That was above the 2.4 volt requirement, so it was >>fine. >> >>When a CMOS technology is spec'd to the same TTL standards on input and >>output (0.8/0.4 low, 2.0/2.4 high) do they *always* pull up to Vdd if >>there is no appreciable load? I never wanted to make any assumptions in >>case there are CMOS outputs that are *not* designed to pull up to Vdd. >> >>-- >> >>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 > >Article: 67819
On Fri, 19 Mar 2004 10:10:01 -0800, Mike Treseler wrote: > arvind wrote: > >> So can anybody give me the Short and Sweet >> answer about my Question "why it is recommended to avoid latches in >> Digital Designs?" > > Because latches are incompatible with synchronous > design and automated static timing analysis. > > -- Mike Treseler Nonsense. I'll grant that it's harder to do a static timing analysis on a latch based design but it's perfectly doable. In an ASIC a latch design has a lot of advantages, latches have 1/2 transistors of flipflops (not applicable to FPGAs) non-overlaping clock latch designs are less sensitive to clock skew the clock to out of the latch is not in the critical path There is a delay averaging effect, i.e. if one stage of a pipe is fast and the next is slow, the slow stage gets to use the spare picoseconds left over by the fast stage. All of these things contribute to a faster clock rate. In an FPGA there are fewer advantages to doing a latch based design then in an ASIC. Flipflops and latches have the same cost in a FPGA, the clock trees are well defined so the clock skew advantage isn't there, and finally other things are likely to limit your clock speed so the improved performance of latch based data path is unlikely to help you. The disadvantage of a latch based design is that it is harder to do so unless you really need the maximum possible performance you are generally better off using a register based design, especially in an FPGA.Article: 67820
Hi, I am amazed at how SysAce handles the hardware and software: the ACE file should have 2 parts, FPGA programming bit file and the ELF file which will be loaded into external memory. I know the trick is JTAG, but I want to get a closer look what the underneath flow is. SysAce load the bit file to program the FPGA, and then it ask PowerPC to load the ELF to the external memory? What exactly happens? I check out the data sheet of SysAce CF, but it does not mention this flow. I wonder if somewhere else has this? Thanks.Article: 67821
Hi Valentin, If you don't include the ROC component in your VHDL design then your functional/behavioural simulations won't show the long reset. The ROC component is inserted automatically (if you haven't included it) during back-annotation by ngd2vhdl for post implementation timing simulations.By default this reset is for 100ns. Refer to the section on Emulating the Global GSR pulse in VHDL in Functional Simulation in Synthesis and Verification Design Guide. Sudhir "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in message news:<c3ebsc$25po73$1@ID-212430.news.uni-berlin.de>... > > Also use the following library: > > library UNISIM; > > use unisim.vcomponents.all; > > search for ROC at Xilinx website, you'll find lots of info there. > Thank you for the idea. But I'm missing something: UNISIM is post-synthesis > library. However, functional and post-synthesis simulations don't require > long reset. This problem is observed only in timing simulation.Article: 67822
"Kevin Brace" <k0evinbr1ace@m2ail.c3om> skrev i meddelandet news:c3f37u$qa4$1@newsreader.mailgate.org... > Hi Spike, > > I own the Insight Electronics PCI card mentioned in the article, but it > has been discontinued some time ago and replaced with a newer version. > > http://www.insight.na.memec.com/Memec/iplanet/link1/SpartanII200PCI.pdf I looked at the "Included" list and didn't find any IDE or similiar for development of VHDL programs. Do I have to buy that separate? > > > You might also want to consider Avnet Spartan-3 evaluation card if you > don't mind the higher price and a minor violation of the PCI > specification (i.e., voltage converters between the Spartan-3 and the > PCI card edge.). > > http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D7816%2526CCD%2 53DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID%253D0%2526PVW% 253D%2526BID%253DDF2%2526CTP%253DEVK,00.html > > > Spike, have you considered what to do with the PCI interface > once you purchase the card? While I'm waiting for the card I will try to read some books on FPGA's, VHDL and so on. Once I get it I will try to test a couple of test - examples that I hope are included just to see how the machine really works. After a while I will try to build a valid PCI Configuration Space (what Vendor/Device ID's did you use? are there any reserved for hobby purpose?) to test if my PCI design works. As soon as the design works I will try to read the PCI spec(s). more carefully to learn how the mechanical & electrical parameters should be implemented. But the real purpose of building a PCI card will be (in the beginning) just for fun. After a while I might try to build a I/O controller and maybe add something more advanced. If you know of any good books on VHDL, FPGA with PCI in mind or similar I would be glad if you could tell me. How did you start? Thanks for your help! //SPike > I am planning to release a PCI IP core I developed around end of May. > It will be available for $100 as long as the user agrees to use it for > non-commercial, non-profit, non-academic research, and personal > purposes. > The licensee will need a PayPal account to send the payment, and a Yahoo > account to download the PCI IP core. > I was originally planning to make the PCI IP core was going to be > available only to people residing in the United States who have a valid > PayPal account, but I changed my mind, and it will now be available to > people who have a valid PayPal account living overseas as well. > > > Here is what my PCI IP core will look like: > > * PCI Local Bus Revision 2.2 compliant. > * Burst initiator/target access support. > * 6 Base Address Register (BAR) and Expansion ROM BAR support. > * Meets 33MHz PCI timings with Spartan-II-5 > * General purpose PCI testbench comes with a PCI arbiter, PCI host > bridge emulator, and PCI target device to allow the user to quickly > debug their design. > * The PCI IP core supplied in NGO netlist format (Xilinx's proprietary > netlist format.). > * Nominally supports Xilinx Virtex, Spartan-II, or newer FPGAs. > * Constraint file supplied for Spartan-II PQ208 and FG456 package, > Virtex-E XCV300E BG432 package, Insight Electronics Spartan-II 150 PCI > card, and Spartan-II 200 PCI card. > * Comes with three reference designs (Two similar target only designs > and one target/initiator design.). > * Fully supports Verilog (Reference designs and the PCI testbench are > written in Verilog.). > * Limited VHDL support (No reference designs and PCI testbench. Verilog > version of the reference designs and PCI testbench will eventually be > ported to VHDL.). > * Supports ISE WebPACK 3.2 through ISE WebPACK 6.2 (The use of ISE > WebPACK 5.1 or later is strongly recommended.). > > > > Kevin Brace > > P.S. Remove the weird numbers from the E-mail address when contacting > me. > > > > Spike wrote: > > > > Hi again! > > > > I just looked at this: http://www.xilinx.com/xcell/xl38/xcell38_13.pdf, but > > I'm not sure where I can buy it and whether or not it fulfills me needs... > > Has any one tried it? > > > > //SPikeArticle: 67823
"Eric Crabill" <eric.crabill@xilinx.com> skrev i meddelandet news:405B39BC.3530BAAA@xilinx.com... > > Hi, > > You, or anybody else who's interested in a Virtex based PCI > prototyping board, can go to: > > http://www.engr.sjsu.edu/crabill/projects/nxm/readme.htm > http://www.engr.sjsu.edu/crabill/projects/nxm/ > > Download the gerber photoplots, bill of materials, and > schematics. You can build some for yourself and sell the > rest if you want (I don't care...) I planning on only using FPGA's for fun so no profit is involved. > > Eric How do you upload the program to the FPGA? As far as I know FPGA's doesn't haave support for EEPROM so another deivce would have to upload it (I would be very glad if you could prove me wrong on this one!). Also, What kind of PCI cards have you developed with the help of this card? Have you experienced any problems? Thanks! //SPike > > Spike wrote: > > > > ok, I would like to make my own PCI board (a stand-alone PCI card which I > > can insert in an computer with a free PCI slot). Nothing fancy just a board > > that could send out I/O data or what ever. > > > > For this task I've heard that FPGA would be a good choice. > > > > I don't know how to explain it better but if I've missed something, let me > > know. > > > > Thanks! > > > > //SPike > > > > "rickman" <spamgoeshere4@yahoo.com> skrev i meddelandet > > news:405A4A18.5555C689@yahoo.com... > > > Spike wrote: > > > > > > > > I can't say I know enough about FPGA processors to choose a good one, > > that's > > > > mainly why asked this question. I was hoping that you could give me some > > > > advices... > > > > > > That will require that you explain in detail what you want to do with > > > it. And be prepared for a lot of advice on what you want to do as well > > > as how to do it... ;) > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67824
Hi guys, This is what I get from Xilinx datasheet, please confirm me if I am wrong: The IOB programmable delay has only two modes delay/nodelay. When delay is implemented, it add just 100ps to data path.
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