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
Tom Burgess wrote:<snip> To solve the slow global reset problem, how about circuitry on each clock buffer that > could disable it during reset, then synchronously re-enable it N clocks after > end of reset, where N is programmable (0 for no delay), up to some reasonable maximum > sufficient to accomodate the reset recovery time and max clock rate. Or some simpler > scheme that would accomplish the same thing. You have that capabilty, kind of, today in Virtex-II, where each clock buffer has an enable input. What's missing is a timing circuit that blocks the clock appropriately. Read the description of the BUFGCE in the newest version of the data sheet that goes on the web this coming week ( and also to the printer soon thereafter) Peter Alfke, Xilinx Applications > > >Article: 35676
The Spartan-II PCI board worked in two computers both in room temperature (about 20 degrees Celsius). I have never worked with FPGAs up to that point, so I was pretty anxious to program the external PROM, and see if the board will work. The board somehow worked, so since then I haven't programmed the external PROM because I haven't finished verifying the IP core completely, and haven't been able to meet 33MHz PCI's timings. Regards, Kevin Brace (don't respond to me directly, respond within the newsgroup) Ray Andraka <ray@andraka.com> wrote in message news:<3BC6E864.9F3363A9@andraka.com>... > The timig analysis is worst case timing, which happens with high temperature and low supply voltage. In my experience, > Xilinx FPGAs will genarally work up to about 40% above the max frequency listed in the timing report in a lab environment > (watch that temperature though). I wouldn't go pushing these for something that is going to go out of the lab though.Article: 35677
FYI, using VS.NET beta 2 VC++, good old "hello world" is 3.5 KB compiled -MD (use C runtime DLL); and 36 KB with the whole, sprawling, statically linked C runtime stdio. Jan Gray, Gray Research LLC (ex VC++ dev)Article: 35678
"Ras Sim" <simsek@rhrk.uni-kl.de> wrote in message news:<49a92f681fea693317ee5a82213a3519.32396@mygate.mailgate.org>... > Hi folks! > I'm a student and i need a free PCI-Core wich is written in vhdl. > Where could I download it ? > > Greets > Rasit You can download try version PCI-Core from Altera SOFT-IP page. The PCI compiler contain four kind PCI-Core function,you can download it and simulate with your core design. When you finish simulation and decide to program Altera device,you should purchase it. Altera soft-ip product site: http://www.altera.com/products/ip/ipm-index.html I suggest that you must have some knowledge about PCI bus. Please reference some PCI bus book. I am sure that the PCI bus timing protocol is complex. So you at least must have enough knowledge befor combining your core design with PCI-CoreArticle: 35679
Tim <tim@rockylogic.com.nospam.com> wrote: > Maybe the long term plan is to configure/readback the big stuff > via JTAG only - the details of ROM handling can be farmed out to a > PAL. Won't that be painfully slow for large devices? Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 35680
Theron Hicks wrote: > I would think that a built-in crystal oscillator port would be a great > option. Also, I personally would like to see real LVPECL (i.e.suitable > for single ended LVPECL inputs) with real LVPECL levels. Also packages > with pins (SMT pins are OK but not those ball grid arrays) for those who > are using FPGA's as a short production run (read PROTOTYPE) device. > > Theron Hicks While we're on the subject of what Austin Lesea calls the V-3 hopper: Why not allow the drive strengths of the LVTTL/LVCMOS pins to be dynamically configurable so I can set my DRAM outputs dependent on how many, how big DIMMs are actually populated ?Article: 35681
Ken McElvain wrote: > We are here... > > We do appreciate getting small examples that demonstrate potential > improvements. In general there is no need to go to the effort > to produce the structural form. All we need is a short description > of what we missed - "You should have used the synch reset instead of > building it in logic in front of the flip-flop". > > We have a large queue of improvements sorted by a function of how > common they are, how much gain we are likely to get and how hard they > are to implement. This doesn't mean that you shouldn't bother to tell > us about your desired improvement. Even if we already have it in our > queue, you are bumping our notion of how common the problem is. > > The best way to send us such a test case is via email at > > support@synplicity.com > > Please put both "QOR" and the target FPGA in the subject to > help us route it. The FPGA synthesis development team is pretty large. > > Thanks, > Ken McElvain, CTO > > Andrew Brown wrote: > > Ken, The problem here is that there is no feedback. In other words what would help is a publicly accessible database of problems/inefficiencies and their workarounds/solutions like the Xilinx answers DB. It sometimes seems that when I (maybe others as well) send in a bug report it seems to vanish into a vacuum. I get an acknowlegement that there's a problem and that's it. It gets worse when, as in a recent test case of mine, I send in what appears to be a Xilinx MAP problem only to get told by Xilinx that its really a synthesis problem and its been passed over to Synplicity. This needs to be combined with a lisiting in the release notes for each version of all issues (bugs + imporovements) that have been fixed. ModelSIM is the paragon here. I do appreciate that HDL synthesis is complex and there's always the possibility that fixing one thing will break something else or that my ``bug'' may be unique to me; stemming perhaps from pushing the boundaries of synthesisability. That information is, in itself, very valuable. IMO Synplify is the best of the bunch - at least for Xilinx parts - but with some attention to the issues above you could win the engineer's ultimate accolade `Synplify ? Great tool, low hassle'. As a test case that's relevant to this thread since the problem relates to the reset type - async/sync: What's the status of bug report #33437 (register replication) ?Article: 35682
Mike Treseler wrote: > Juergen Otterbach wrote: > > > > Hallo usergroup, > > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA > > device. > > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA > > (means to take of the 1000E and resolder the 2000E). > > Removing and replacing a BGA device is not > a problem for any manufacturing facility > with a BGA rework station. > > Of course, you have to throw the old part away. > > Without the proper equipment and skills > however, you may well destroy the board. > > --Mike Treseler We had a case some years ago where our assemblers had fitted a bunch of XCV300-432BGAs 90 degrees rotated !! They had a re-work station and did manage to get the parts off *but* they lost some of the pads doing it. These were all on n/c balls and so we were o.k.. I believe the reason was that n/c's have much less heat dissipation (no trace or pwr plane connection). The real issue is that a BGA re-work station uses a metal box which is placed over the BGA to form a mini-oven but, unlike the main re-flow oven, the whole board doesn't go through the preheat, temperature profiling process. Things may have got better since then ...Article: 35683
hi, you can specify a faster clock speed by changing the grid size of the waveform editor. Thatīs very easy. PhilArticle: 35684
The timings you get from the timing analyzer are based on worst case supply voltage, temperature and the maximum load capacitance allowed on a PCI bus. Additionally the setup and clock-to-out specifications of the PCI standard are based on a PCI bus with maximum trace length, maximum number of slots and all slots populated. If you want to sell a PCI core you better have it meet the worst case timing specifiaction, but for your own experiments that is not necessary. The last compile of my own PCI core has a clock-to-pad of 13.5ns and a setup time of 9.3ns and runs stable at 33 MHz in a fully populated PCI-Bus. If you want to be on the safe side you can change the PCI clock frequency of you mainboard to 25MHz which will give you an extra 10ns margin that can be devided between setup and clock-to-out times. Also leaving some PCI slots empty should give you a couple of extra nanosecods. See chapter 4.3.5 of the PCI standard. Do not be too paranoid. It is perfectly normal for PCI boards to not to comply with the standard. (Thats probably one of the reasons why many PCs run unreliably.) - For example there existed PCI boards that only decoded 16-Bit of the IO address space. - Many boards do not signal parity errors. - I have an old VGA boards from a Compaq 75 MHz Pentium system. The board will only run at 25 MHz. - I have not seen a single 5V board that fulfilled the decoupling requirements of chapter 4.4.2.2 an so on, and so on.... Kolja Sulimma Kevin Brace wrote: > The Spartan-II PCI board worked in two computers both in room > temperature (about 20 degrees Celsius). > I have never worked with FPGAs up to that point, so I was pretty > anxious to program the external PROM, and see if the board will work. > The board somehow worked, so since then I haven't programmed the > external PROM because I haven't finished verifying the IP core > completely, and haven't been able to meet 33MHz PCI's timings. > > Regards, > > Kevin Brace (don't respond to me directly, respond within the > newsgroup) > > Ray Andraka <ray@andraka.com> wrote in message news:<3BC6E864.9F3363A9@andraka.com>... > > The timig analysis is worst case timing, which happens with high temperature and low supply voltage. In my experience, > > Xilinx FPGAs will genarally work up to about 40% above the max frequency listed in the timing report in a lab environment > > (watch that temperature though). I wouldn't go pushing these for something that is going to go out of the lab though.Article: 35685
May I suggest a slight change ?
if cnt = 0 then
cnt <= pwm_width ;
else
if direction = '1' then
cnt <= cnt+1;
else
cnt <= cnt-1;
.....
pwm <= direction ;
pwm will be 1 for (2!!n- pwm_width) and 0 for pwm_width+1
the only change is : this implementation should not be
decoder dependant as the condition is always zero
regards
--
User of http://www.foorum.com/. The best tools for usenet searching.
Article: 35686Could anyone point me to references (hopefully on-line) for implementing asynchronous (self-timed) designs using (in particular) Xilinx FPGAs? I am aware of the literature on asynchronous design in general, and am interested in whether anyone has completed non-trivial designs in FPGAs, and in moderately specific techniques for doing this. TIA, -- PhilArticle: 35687
I wonder if the DDR output flipflops in Virtex-II might be a solution for you.
They are designed to run of both edges of your clock, take two
data streams, and interweave them, and do it without glitches. If you did this
the result signal would be an output, and would use a pin. You could
route the result bak in over the PCB, or just add an input buffer in the same
I/O cell to bring the result back in for your ongoing enjoyment.
Philip
On Fri, 12 Oct 2001 23:33:07 +0100, "Johan Ditmar"
<johan.ditmar@nospamceloxica.com> wrote:
>Hello there,
>
>The past few days I have been trying to come up with a way to describe a
>generic pulse generator in Verilog (or VHDL) using shift registers. What I
>would like it to do is to take an arbitrary pulsetrain as a parameter (for
>example "100110") and then generate this pulse train repeatedly from an
>incoming clock signal. However, each bit in the pulse train corresponds to
>half an incoming clockcycle! I came up with the following scheme to do this:
>
>I implement two rotating shift registers (A and B) of three bits wide, one
>that is sensitive to the positive clock edge and one on the negative. I
>initialise one with the even bits of the pulse train ("101") and one with
>the odd ("010") and I let them run on the incoming clock.
>
>Then I generate a signal from the incoming clock, which simply follows this
>clock (using two flip flops, one positive and one negative edge sensitive),
>and I use this signal to either choose the output of shift register A or
>shift register B and this is then the output of the whole circuit.
>
>However, the output of this circuit is going to be used as a clock which
>feeds other circuits, so it should be glitch free. This is not always the
>case in my present design (I think). Is there some way to make my design
>glitch free? As the output changes on both positive and negative clock edge,
>I canīt put a simple register on the output :-( And I prefer not to use
>PLLīs or DLLīs (which may be used to generate the double clock frequency to
>make everything sensitive to the positive clock edge only).
>
>Any help is greatly appreciated!
>
>Regards,
>
>Johan Ditmar
>
>
Philip Freidin
Fliptronics
Article: 35688Thanks Jim, appreciated. Regards, Gerry. In article <3BC7A69C.37B@designtools.co.nz>, Jim Granville <jim.granvill e@designtools.co.nz> writes >Gerald Coe wrote: >> >> Hello >> >> This is a concern to me, >> Can you provide an on-line reference to this document? > >Lattice have just modified the links, and added these two > >http://www.latticesemi.com/lit/docs/pcns/010a_01.pdf > >http://www.latticesemi.com/lit/docs/appnotes/cpld/tn1007.pdf > >This details the affected devices, including those that will require >PCB redesigns. > >-jg > >> In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt >> <martp@hotmail.com> writes >> >Hello, >> >as I read in comp.arch.embedded most i186 and i486 derivates build by >> >AMD are discontinued. >> >Now we got an announcement that this is the case also for a great >> >bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is >> >intended to be closed). >> >The list of devices in the PDF document spans 8 pages and contains >> >PALCE PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx >> >devices! >> > >> >Last order is 31 dec 2001 and last delivery 31 dec 2002!!!! >> > >> >I have posted this using another mail server a day ago, but I havent >> >seen it up to now. >> >I apologize if this message is reaching you twice. >> > >> >Perhaps we are the only ones around using this old-fashioned >> >programmable devices.... >> > >> > >> >BTW: On http://www.latticesemi.com/products/mature/index.cfm >> >you cannot read **anything** about this up to now (12 oct 2001, 11:20 >> >UT) >> >> -- >> Regards, Gerry >> www.robot-electronics.co.uk -- Regards, Gerry www.robot-electronics.co.ukArticle: 35689
There was a group in the UK that had done some of this in FPGAs. Be
aware, however, that this will involve a serious amount of handcrafting
for a robust design. Cover terms necessary to avoid logic hazards are
optimzed out by the automatic tools, so you need to instantiate the
logic as LUTs or extensively use keep buffers in your design to keep the
logic constructed to avoid hazards. The FPGA clocking is specifically
designed for synchronous design. A self-timed design, in most cases is
going to make half the flip-flops unusable because the twoflip-flops use
the same clock. FInally, the timing analysis is greatly complicated,
and is not supported by the current static timing tools.
For these reasons, the self timed stuff to date has been for much
smaller designs than those commonly done with synchronous logic.
Phil Short wrote:
> Could anyone point me to references (hopefully on-line) for
> implementing asynchronous (self-timed) designs using (in
> particular) Xilinx FPGAs? I am aware of the literature on
> asynchronous design in general, and am interested in whether
> anyone has completed non-trivial designs in FPGAs, and in
> moderately specific techniques for doing this.
>
> TIA,
>
> --
>
> Phil
--
--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: 35690I'm trying to get familiar with Xilinx ISE 4.1i this weekend and have the following problem... I instantiate a design element macro in my Verilog code such as .. OFD u1 (.I(q),.O(q),.C(clk)); but when I Synthesize, I get warnings beginning with... Warning: Cannot link cell 'test/u1' to its reference design 'OFD'. (FPGA-LINK-2) and Warning: The cell '/iotest/u3' is not linked to any design. (FPGA-CHECK-4) If I ignore the warnings and "Implement Design," I get an error... ERROR:NgdBuild:604 - logical block 'u1' with type 'OFD' is unexpanded. Symbol 'OFD' is not supported in target 'virtex2'. This doesn't happen with "primitives," only with "macros." What am I doing wrong? mchampion@Xbigfoot.com (remove the X to send me email)Article: 35691
I am targeting Xilinx Virtex II with Verilog in an ISE4.1i environment. I want to instantiate (or infer) a single IOB which has I/O capability, registered output, tristate output control, and registered input. Both registers can use the same clock. I expected to find a design element in Xilinx's Library Guide, but there is none. All of my attempts so far result in one or both registers being moved out of the IOB into a CLB. This won't work with my speed requirements. TIA mchampion@Xbigfoot.com (remove the X to send me email)Article: 35692
Pack flops into IOBs via switches to the mapper. From memory it is something like '-pr b'. Run map with no arguments to get the switch list. Virtex designs use regular flops in the IOBs, unlike 4K, etc., which had magic IFD/OFD flops. "Marko" <cantsay@here.com> wrote in message news:3bc9bc39.59939438@dfiatx1-snr1.gtei.net... > I am targeting Xilinx Virtex II with Verilog in an ISE4.1i > environment. I want to instantiate (or infer) a single IOB which has > I/O capability, registered output, tristate output control, and > registered input. Both registers can use the same clock. > > I expected to find a design element in Xilinx's Library Guide, but > there is none. > > All of my attempts so far result in one or both registers being moved > out of the IOB into a CLB. This won't work with my speed > requirements. > > TIA > mchampion@Xbigfoot.com (remove the X to send me email)Article: 35693
<hamish@cloud.net.au> wrote > Tim <tim@rockylogic.com.nospam.com> wrote: > > Maybe the long term plan is to configure/readback the big stuff > > via JTAG only - the details of ROM handling can be farmed out to a > > PAL. > > Won't that be painfully slow for large devices? I guess. For the XC2V10000 the times work out as JTAG 1000ms (33MHz, 1-bit) Slave Serial 500ms (66MHz, 1-bit) SelectMap 60ms (66MHz, 8-bit) Since this is a high-speed serial world, and JTAG is usually limited to <50MHz (33MHz on Virtex) the future is presumably a smart JTAG extension.Article: 35694
Andy Peters <andy@exponentmedia.deletethis.com> wrote: > > Uh oh! The person who posted Synplify's results for that 56-bit counter > problem is in line for an ass-whooping! > > -a Andy, They haven't remotely detonated my key ( or my ass ) yet :) According to the Synplify license ( excerpt copyright Synplicity ): "Licensee acknowledges that the scope of the licenses granted hereunder do not permit Licensee (and Licensee shall not allow any third party) to:" <snip> "(iv) disclose the results of any benchmarking of the SOFTWARE, or use such results for its own competing software development activities, without the prior written permission of Synplicity;" Personally, I wouldn't consider answering a question on how to make a counter synthesize better to be a "benchmark"... But then again, nor would I make the software guys writing the synthesis tool insert a copyright message into any cuts and pastes done from the online help code examples... Brian p.s. : upon further reflection, perhaps I should have checked to see if posting an excerpt of the license terms is a violation of the license...Article: 35695
Ray Andraka wrote: > > For these reasons, the self timed stuff to date has been for much > smaller designs than those commonly done with synchronous logic. > Seems like a lot of work if you have to battle with your tools the whole way. I guess you have to really be determined to implement a self-timed design in a Xilinx FPGA. -- PhilArticle: 35696
>From the Webpack XST license ( excerpt copyright Xilinx ):
"2. Restrictions."
<snip>
"You may not publish any data or information that compares
the performance of the Software with software created or
distributed by others."
( Had I posted both license excerpts in the same message, would
that constitute 'license benchmarking' ? )
----------------------------------------------------------------
> Uh oh! The person who posted Synplify's results for that 56-bit
> counter problem is in line for an ass-whooping!
Upon even more reflection, should it come to that, I could
probably plead insanity vis-a-vis my original counter post:
JUDGE: How do you explain this egregious posting of useful
information?
DEFENDANT: But your Honor, after reading 3000 responses about
asynchronous resets and GSR, none of which clarified the cause
of the coherently cleared counter curiously containing copious
CLBs, I just HAD to post a message explaining the paradoxical
result that lowering the synthesis target frequency would result
in a counter that is both smaller and faster after P&R.
JUDGE: For your offense, and in the light of your excessive
alliteration of words beginning with the letter "C", I hereby
sentence you to use FPGA Express for all future synthesis work.
Bailiff, take him away.
Brian
Article: 35697Hi, Tim wrote: > Another point of view... > > I disagree on the dual-use of pins. Could you explain why you disagree ? What kind of problem would it create for your app ? > Please put ALL the config, etc, > pins on the VCCAUX supply. Here too, it would be better if you could explain why. > I.E. on non-banked balls. Maybe I miss something here, but I really can't see why it could be a problem that D0-D7 and other signals are part of a IO bank as they are now. With the selectMap mode, you can keep them dedicated if you need to (they call it the "persist" option) so you get the best of both worlds. > I guess we could > also have an option to connect some of these to the logic matrix. The > V2 lineup is so much better than the 4K/Virtex arrangements, but it is > still annoying to have config spread between VCCAUX and whatever > voltages banks 4 and 5 are set at. Maybe all the pins that are already dual use would do better if they were grouped on a single or a separate bank. However, I don't see where the problem is for you since you seem to to configuration through JTAG and you don't use these pin's alternate function. > > Maybe the long term plan is to configure/readback the big stuff > via JTAG only - It's not because you don't use other configuration methods that they're useless. Also, as Hamish Moffatt wrote, JTAG speed is not too fast. SelectMap is around 16x faster. Should xilinx forget about Jtag and promote SelectMap as the only way to configure / readback an FPGA ? Certainly not ! Both are possible, choice is yours. > the details of ROM handling can be farmed out to a > PAL. Requiring an added, (soon to be obsolete) PAL chip where the FPGA could do it at no extra cost and without any consequences for other users escapes me (Am I missing a major drawback here ?). Similarly, the details of proper signal termination can be farmed out to a bunch of discrete resistors. However, Virtex II integrates the function on chip and users who need it welcome this added function. Others simply don't use it. The most important question here is whenever there is enough demand for that parallel master mode with an added address generation counter feature. I think there is, mostly for system that closely integrate processors and FPGAs, and also for systems that need large / fast reprogrammable configuration memory (an XCV2600E requires 4x XC18V04 while a single, standard flash rom such as this one: http://www.ssti.com/products/39lf_vf080_016.html would do, up to a XCV3200E ). One thing that's important is that if any of these enhancements are made, they should be transparent for users who don't need them. regards, Eric.Article: 35698
Tim <tim@rockylogic.com.nospam.com> wrote: > <hamish@cloud.net.au> wrote >> Won't that be painfully slow for large devices? > I guess. For the XC2V10000 the times work out as > JTAG 1000ms (33MHz, 1-bit) > Slave Serial 500ms (66MHz, 1-bit) > SelectMap 60ms (66MHz, 8-bit) Hmm, that's not so bad. We're byte-banging from the CPU (through a CPLD) in SelectMap mode and it takes a couple of seconds already for an XCV2000E. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 35699
In comp.arch.fpga Marko <cantsay@here.com> wrote: > I instantiate a design element macro in my Verilog code such as .. [..] > This doesn't happen with "primitives," only with "macros." > What am I doing wrong? In my experience, you can't instantiate Xilinx macros in your HDL code. Ngdbuild doesn't know anything about them (only primitives). You can use macros in schematics and in this case your schematic editor's netlist writer must expand the macros. In this case you must instantiate an FD + OBUF. Or infer the FD and instantiate the OBUF. Or better yet, infer both (if your synthesis tool is half-intelligent). Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
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