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
Phil Hays wrote: > I'm looking at a design with an interesting PCI issue. What I need to > know is what does a x86 BIOS (on a compact PCI board) do with a very > large base address register: to wit 256 GB? > > This BAR is far too large to map into the CPU's 4 GB limit. Even if the > CPU had the new Intel paged address scheme (4 extra address bits, for 64 > GB total??), it still wouldn't have enough address space to map this. > What does a BIOS do? Even more to the point, what should a BIOS do? > > While this BAR is on a bus the CPU sees, the CPU doesn't need to access > this memory space. It is for communication between other devices on > this PCI-X bus. If the BIOS just left it alone, unmapped, that would be > just fine... But does it?? > > Any suggestions? Hints? Wild guesses? I'm replying to my own topic as nobody else did. The answers I've gotten elsewhere have not been encouraging. I'm thinking of modifying the Xilinx PCI-X core to allow enabling the BAR after the Bios is done setting address spaces. The very large BAR will be disabled by setting the relevant part of the "config bus" from registers rather than from tying it to levels. This will allow the BIOS to not see this BAR, and thereby ignore it completely, and the driver loaded with the OS to configure this BAR as needed. Anyone ever try this? Did it work? Or not? Any other suggestions? Hints? Wild guesses? Anything??? -- Phil HaysArticle: 54901
Thanks for the info Jesse, As it turns out, I aborted the right if the handshake was cancelled. As it turns out, my test interface (external hardware) was bouncing all over the place resulting in a very high frequency of data writes. Occasionally, a new write would be requested before the old write was processed fully resulting in a memory drop. Me bad. kempaj@yahoo.com (Jesse Kempa) wrote in message news:<95776079.0304180916.c7c584f@posting.google.com>... > Hi Jim, > > I've made a couple avalon masters for various projects and while I > haven't seen the exact behavior you're seeing, I have a couple ideas - > you might have given these a try already... > > First off, a rather silly one: Sounds like the addressing is coming > along fine, but what about the other control signal(s) (read, write, > etc.)? Are they synchronous with the address bus on the 'avalon > domain'? Really, as long as read or write is asserted before the > 'avalon domain' cycle where the address is presented, then you're > fine. The same applies to the writedata bus. > > It would also be prudent (in the case of rd/write/data coming from > your other clock domain) to see that the control signals & data are > being held long enough - until the next avalon domain clock edge after > waitrequest goes low. > > > > > However, I'm still stuck with an occasional failed memory write. > > Through the same software debugging, it appears that the data was > > never written to the RAM (at the desired address or otherwise). This > > makes sense since the address calculation is performed in it the same > > clock domain one cycle before the initiation of the actual write > > sequence. In addition, I check that the 'waitrequest' line is low > > (inactive) before releasing the write_n line. > > > > By design, if the write sequence does not execute within 30-35 clock > > cycles from the receipt of the handshake, it will be aborted. I'm > > assuming that a Avalon Bus Master write sequence to memory, even with > > the occasional 'waitrequest', should execute within a few clock > > cycles. > > > > The other thing that comes to mind is this timeout logic. For a simple > on-chip memory (as opposed to something like SDRAM where refreshes > occasionally happen) there won't be much delay in getting waitrequest > to go low, even if contention exists with another master (another > silly one: do you have a high arbitration priority setup for any other > masters talking to the memory?)... > > To rule out this as a possibility, I would try signal tap, or just > code a single read register (CPU-readable avalon slave) which is > loaded by the maximum # of clocks waitrequest is seen high during > attempted write transaction on the master. > > Jesse Kempa > Altera Corp. > jkempa @ altera dot com (nospam: remove the spaces)Article: 54902
Here's a tough one: Where can I find the source of NIOS CPU interrupts not assigned in SOPC Builder? If I trap interrupts, I tend to capture #1, #11, and #13 during LAN traffic. These are bad enough to create an infinite reset loop (probably because the interrupt source has not been cleared). Examination of my SOPC Builder NIOS design shows that IRQ #'s are assigned to my components starting at 16 and increasing from there. Also, if I disable "capture spurious interrupts" in the NIOS CPU, am I preventing the interrupts from occurring or are they eating CPU cycles and I just can't see it? I haven't been able track down this information using the Altera Knowledge Base. Looking for some help on this one. Thanks! JimArticle: 54903
Steve,
Regarding the muxes, I believe you are mistaken on the cost in the Altera parts.
The fast cascade chain can be used tocombine LEs in a manner that is at least as
flexible as the MuxF5's in the SpartanIIe. You get 2 LE's for a 4:1 mux using the
cascade. From what I have seen, Cyclone does have a speed advantage over
SpartanIIe for typical designs. The big advantage the Spartan has in my
applications is the SRL16, which provides an ability to make a DA filter
reprogrammable without having to do a device reconfiguration, not to mention the
obvious delay queue shrinks.
Steve Knapp wrote:
> Sorry, but I feel the need to clean up a few common misconceptions.
>
> Only Spartan-II FPGA (non-E) family, announced January 2000, is 0.18u.
>
> Spartan-IIE is 0.15u and has been in volume production for over 18
> months now. Still, Cyclone at 0.13u potentially has a 25% area
> advantage (potentially a ~25% cost advantage) at comparable densities
> (1-((0.13^2)/(0.15^2)))=25%. However, Spartan-IIE is manufactured on
> 300 mm wafers, which delivers about a 30% cost reduction over 200 mm
> production. Cyclone, I understand, is not yet on 300 mm wafers but will
> be about the same time that the 90 nm Spartan-3 devices start
> production. In production, Spartan-3 will be at 90 nm on 300 mm,
> offering a double cost benefit.
>
> Another posting under this same thread shows that cost is more than just
> LEs. Spartan-IIE solutions at 180+ pins start at just US$16.61 while
> Cyclone starts at $33.20. Some applications need more LEs at this I/O
> range, some don't.
>
> Also, the claim about Cyclone being cheaper per LE is a bit spurious.
> The claim is only true assuming that you never use any of the following
> logic structures.
>
> -- Multiplexers larger than 2:1
> -- Internal bussing structures
> -- Small FIFOs
> -- Delay buffers or serial-in/serial-out shift registers
> -- Multipliers
>
> Take a simple 4:1 multiplexer. How many LEs are required to implement
> this feature in both architectures? Let's define an LE as a LUT+FF pair
> inside the Altera LAB or Xilinx CLB.
>
> Spartan-IIE: 2 LEs, one level of logic
> Cyclone: 3 LEs, two levels of logic
>
> In this simple example, Cyclone uses 50% more LEs and an additional
> layer of logic.
>
> Now expand it to an 8:1 multiplexer.
>
> Spartan-IIE: 4 LEs, one level of logic
> Cyclone: 8 LEs, three levels of logic
>
> Again, Cyclone uses 50% more LEs and an additional layers of logic..
>
> Now, let's look at an example where we have eight byte-wide functions
> connected to a common bus. How much logic is required to create the
> bi-directional bus?
>
> Spartan-IIE: 0 LEs (the architecture has internal three-state
> functionality)
> Cyclone: Requires eight 8:1 multiplexers at 6 per instance, or 48
> LEs.
>
> Now, let's look at a serial-in/serial-out shift register.
>
> Four-deep shift register:
>
> Spartan-IIE: 1 LE (the architecture has distributed RAM/serial shift
> functionality)
> Cyclone: 4 LEs (okay, in reality, it's only the flip-flops that are
> used)
>
> Sixteen-deep shift register:
>
> Spartan-IIE: 1 LE (the architecture has distributed RAM/serial shift
> functionality)
> Cyclone: 16 LEs (okay, in reality, it's only the flip-flops that are
> used)
>
> In this example, 1 Spartan-IIE LE equals 16 Cyclone LEs or in some
> cases, one Cyclone block RAM.
>
> In real applications, Spartan-IIE uses roughly 15% fewer LUT+FF pairs
> than Cyclone. Use Spartan-IIE for any small buffering or DSP
> applications and Spartan-IIE offers even greater advantages.
>
> Many of the Cyclone architectural limitations vs. Spartan-IIE are
> outlined in one of Altera's own application notes.
>
> AN 255: Guidelines to Migrating Spartan Designs to Cyclone Designs
> http://www.altera.com/literature/an/an255.pdf
>
> The question is now "How many LEs do I get per dollar?" The question is
> "How much logic can I implement per dollar?"
>
> These opinion are obviously my own and may not reflect those of my
> employer.
>
> --
> ---------------------------------
> Steven K. Knapp
> Applications Manager, Xilinx Inc.
> Spartan-3/II/IIE FPGAs
> http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Spartan-3
> E-mail: steve.knapp@xilinx.com
> ---------------------------------
>
> Paul Leventis wrote:
> >
> > Hi CB,
> >
> > The biggest advantages are cost, logic density, and performance.
> >
> > Cyclone is a 0.13u device, architected for low-cost. Spartan-IIE is 0.18u
> > device that recycles the Virtex-E architecture. Cyclone is cheaper for
> > almost all applications -- both companies claim the lowest cost part, but
> > Cyclone is much cheaper per LE. Cyclone goes up to 20K LEs, while
> > Spartan-IIE goes up to 13.8K (or 12K vs 9.6K in a 256-pin package). Cyclone
> > is also MUCH faster, partially due to the process advantage and partially
> > due to a superior architecture. This speed can turn into a cost reduction,
> > since you don't need to buy as fast a speed grade, or you may not need to
> > parallelize your data as much (and hence can fit in a smaller part).
> >
> > That's about it without getting into the details of the features.
> >
> > Regards,
> >
> > Paul Leventis
> > Altera Corp.
> >
> > [This is my spammable email address; I have no affiliation with the
> > University of Toronto besides being a student there]
> >
> > "CB" <cb@hotmail.com> wrote in message
> > news:3e9e18e4.32935894@news.compuserve.com...
> > > comparing the spartan2e and cyclone component lines in the 256 pin bga
> > > packages , can anyone please tell me advantages in going with the
> > > cyclone versus staying with the spartan2e , i don't care minor
> > > differences in the ram and i/o but i am interested in significant
> > > advanges the cylcone may have, thank you in advance
--
--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: 54904Hi, I am using Xilinx ISE 4.2i and using XPower for power calculation. I need to know if i am doing something wrong here. After bringing up XPower from within Project Navigator i load the simulation file (.VCD) i have kept all other options (load)at default value But after having done this i am not getting output power, isn't it supposed to calculate the output and input power after having a look at the .vcd file? the last message that i can see is: " Found definitions for xxxx signals in VCD file, beginning to process value changes ... Regards, Vivek VenkatramanArticle: 54905
Hi Petter, Does the PC have its own cygwin or perl installed? It looks like the problem is that it is not finding the perl that should have been installed with Nios/SOPC Builder. In the bash shell you should get "/bin/perl" when typing "which perl". For the PC, your bash env should have the following path: PATH=/cygdrive/<path to Nios/SOPC Builder>/bin LaraArticle: 54906
The Tpsdcm/Tphdcm and Tickofdcm include ALL the effects of clock distribution network using a DCM. You are correct that the data valid window of the flop is widened by the jitter of the DCM, as well as things like uncertainty of the clock distribution tree. However, the DCM does more than just add jitter... In the "standard" configuration (a DCM with no phase shift, and the CLK0 connected to CLKFB via a BUFG), the DCM actually overcompensates - making the effective delay through the clock network (from the input of the IBUFG to the clock port of an arbitrary IOB flop) slightly negative. In other words, the clock arrival at the clock pin of the IOB flop occurs slightly BEFORE the rising edge of the clock at the IBUFG, resulting in the smaller Tickofdcm. More importantly, the Tpsdcm/Tphdcm and Tickofdcm are extensively characterized, and are known to be very accurate. It isn't necessarily easy/meaningful to try and correlate these to the sum of individual delays of the internal components within the device. For example, if you tried to "derive" Tpsdcm/Tphdcm from the characteristics of the IBUFG/DCM/BUFG/clock tree/IOB flop (assuming you had all this information, which you don't), you would end up with a much more pessimistic range, and it wouldn't even necessarily be in an overlapping range with Tpsdcm/Tphdcm. In short, trust Tpsdcm/Tphdcm and Tickofdcm (or the new, source synchronous timing information). Avrum "BobW" <bwalance@ixiacom.com> wrote in message news:3ea467af$1@la-news-01.... > Greetings, > > The Xilinx Virtex-II datasheet shows two different ways of specifying IOB > setup/hold and clock-to-out times -- one with respect to the IOB clock > input, and another with respect to a DCM-deskewed global clock input pad. > > The numbers below are for a XC2V1000-4FG456C > > In the "IOB Input Switching Characteristics" section, Tiopick/Tioickp is > 1.06/-0.45ns min. In the "Global Clock Setup and Hold for LVTTL Standard, > with DCM" section the Tpsdcm/Tphdcm times are 1.84/-0.76ns. This indicates > that if you're using a global clock input, and are using the DCM to deskew > to the BUFG output, then you need more valid data time at an input pad. This > makes sense since the DCM jitter is being taken into account. > > So far, so good. > > In the "IOB Output Switching Characteristics" section, Tiockp is 3.44ns max > (assuming LVTTL 12mA fast). In the "Global Clock Input to Output Delay for > LVTTL, 12mA, Fast Slew Rate, with DCM" section, Tickofdcm is 2.76ns. This > doesn't make sense to me. Wouldn't the DCM's jitter increase the IOB's > clock-to-out time, not decrease it? > > Any help would be greatly appreciated. > > Thanks, > Bob > >Article: 54907
eric - Mtl wrote: <snip> > Beside these gross errors (and a couple others) that should never > happen (a few minutes of testing would have uncovered them), the > whole editor interface is poorly designed. > > I could give a long list of complete examples but just a few would > prove the point: > > - When moving / rotating / mirroring a symbol, it should not connect > (glue itself like an insect trapped in a spider's net) to the lines > it encounters until it's deselected. This (and others) illustrates rather well the industry wide problem of those that write the SW, not actually _using_ it. It is hard to avoid in large projects, but there needs to be more 'usage' emphasis in the design of the SW. > - Default option when deleting a wire should not be to delete the > entire net or (optionally) segment per segment, but to delete all > segments between the previous & next node (deleting the whole clock > net is rarely what you want to do). > > - When a named net is split (eg. to add a buffer) it looks like there > is no way to change the name of one of the halves without the other > also being assigned the new name. The "smallest" half have to be > deleted and redrawn completely. Trying to change a connection from one > named net to another will rename the first one with the name of the > second instead (and you won't be able to complete it anyways). > Call that primitive ... > > - Navigation is definitely not user friendly, and a few thing could help > save a lot of time, such as having more keyboard shortcuts (Numeric > pad "+" & "-" to zoom in / out, a single key to pan so that the cursor > position (on the editing area) becomes the center, PgUp PgDn to > navigate between sheets), auto scroll when the mouse is close to an > edge of the edition area (instead of being forced to do it with the > scroll bars) PADS (PowerPCB) has a fast, efficent numeric pad interface : PgUp / PgDn Zoom in/out, and the current cursor is the Zoom centre. Ins pans, so Current cursor is the new centre. Home makes the sheet/PCB fill the screen. Ctrl-W gives an 'AutoCAD clone soft zoom' where mouse drag-box one way zooms out, the other way zooms in. PADS use 'SH2' as modeless sheet (2) selection - this allows jump from Sheet 1 to sheet 11. Another usefull modeless command, is 'S U2' scans and jumps to U2, on whatever sheet. S U2.11 jumps to Pin11 of U2. Auto-scroll features I'm luke-warm about - hard to control and rather machine speed dependant. A scroll-mouse can also speed schematic work. -jgArticle: 54908
Ian Hickey wrote: > > Yes there are many small 8-pin micros out there which are very cheap sub $1. > The project does have some medium speed requirement but probably could be > achieved with PIC12C508 or MSP430F1101A. > > My main reason for looking for a CPLD or similar was I have years of micro > work and was looking for a challenge. > > Is no one aware of a third tier manufacturer specialising in medium speed > 10MHz to 30MHz logic with small pin count? Currently you have SPLD and (smaller) CPLD to choose from. SPLD come in TSSOP packages, so are quite small, but have quite low register counts. Lattice have just released a MLF package ispGAL22V10. In CPLD, TQFP44 (10mm) is the most common small package. Some offer BGA, but these have problems on single sided PCBs :) TQFP48 (7mm) is appearing 'selectively'. MLF packages are obvious for (smaller) CPLDs, as they have high density and low electrical and thermal impedances, and can be used right down to single sided PCBs. The PLD industry is rather slower at seeing this, than the uC industry. -jgArticle: 54909
Isn't that price for the one-year non-renewable Xilinx only license? If you
want a license that can be renewed on a yearly basis, the cost is much
higher isn't it?
Ken McElvain wrote:
> For about $4k you could get a copy of Synplify which will generally
> save you a bunch of area. Add $1K and you have HDL Analyst which can
> help you find inefficiencies in your RTL. The fact that XST blew
> your area budget is not an argument against RTL.
>
--
--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: 54910
I posted a reply for this filter in comp.dsp suggesting a DA approach.
Arthur Herbert wrote:
> rAinStorms wrote:
> > You could pre-add to improve processing bandwidth: (Zx + Zn-x).bx
> > This means 128 Complex multiplies and adds every 30MHz ... about 4Gigs
> > Performance...
>
> The FIR to be designed has no symetric coefficients (if this is what you
> suggest)
>
> >
> > I would say that this one is challenging :-)
> >
> > Not sure if you will pull it off even with a big one.
> >
> > I would propose you use a big Stratix - with its inbuilt MACs you might have
> > a show.
>
> Might be. Do you think that muxing could help spare some CELLs, i mean
> having a set of 32 Multiplier blocs each processing 8 times 30MHz would
> 'only' use 2 big stratix... innit ?
>
> > Dynamic update ... Are you saying you have to be able to update coefficients
> > while filter running? Dont forget the associated distortion if this takes
> > longer than a sample to do.
>
> Yes. Do you have some references about that sort of distorsion ?
>
> > All memories can be configured as dual port ... if you dont need update in
> > one sample then its easy.
> > If you do ... then there are lots of memory ESBs on the Stratix so you can
> > mux them - providing a way to update all coefficients at the same time. This
> > would slow the whole thing down due to muxes.
> >
> Thanks a lot for your advices,
> Arthur ;)
> >
> > "Arthur Herbert" <herbert.arthur@caramail.com> wrote in message
> > news:3EA3B77A.1020305@caramail.com...
> >
> >>Hi -
> >>
> >>I would like to implement a 256 tap complex FIR filter.
> >>It should run at 30MHz and latency should be lower than 200ns...
> >>Moreover, the coefficients should be updatable 'live', ie, without
> >>interrupting the filtering process...
> >>Seems to be quite a hard task !
> >>Does anyone have an idea of FPGA implementation ?
> >>What kind of circuit should be used ?
> >>How many CLB/LE would it take ?
> >>Thanks in advance
> >>
> >>Arthur
> >>
> >
> >
> >
--
--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: 54911"Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> wrote in message news:<p1Coa.2641$KF1.85886@amstwist00>... > Hi Joona, > > > Can I use bidirectional mode with differential LVDS? Target device > > will be Altera Cyclone. > > I know there are two kinds of resistor connection for transmiter and > > receiver (Altera application note 254, figure 3 on page 5 > > http://www.altera.com/literature/an/an254.pdf ). > > But I need a transreceiver. Should I use same connection as with > > transmitter or something else? Or is only way to have transmitter and > > receiver pins & resistors and then connect them to together? > > I ran into this a few weeks back. > > Quartus will refuse a bidir with LVDS as its I/O standard, so it'll be > either LVDS out or LVDS in. However, SSTL-2 standard uses the same > signalling levels as LVDS, although it has less drive current. So, if you > only have a point-to-point bidirectional channel over a fairly short > distance this should do the trick. > > If the Cyclone has to drive a lot of inputs you might run out of steam > because SSTL-2 might not have enough drive to attain the proper slew rate. > > Hope this helps, > > > > Ben Thanks Ben! I'l try SSTL-2 does it work in my case. Also it was good to hear that Quartus has no support for bidirectional LVDS. I haven't seen Quartus yet, but I will soon, hopefully. Thanks, Joona RArticle: 54912
Hello! Hmm, I belive this is the same idea what I suggested by myself. Maybe it's better to design PCB so that this way and using SSTL-2 (what Ben told) are both possible to get in use. Then I could test which one works better. Yours, Joona R "TC" <noone@noplace.com> wrote in message news:<b7vj5f$1gq$1@slb6.atl.mindspring.net>... > Why not a dedicated pair of wires for transmitt, and a dedicated pair of > wires for receive? > > TX in node A to RX in node B, TX in node B to RX in node A. A full-duplex > connection. > > TC > > "Joona R" <jonesky1@hotmail.com> wrote in message > news:2f3990c3.0304200441.5626b7b7@posting.google.com... > > Hello! > > > > Can I use bidirectional mode with differential LVDS? Target device > > will be Altera Cyclone. > > I know there are two kinds of resistor connection for transmiter and > > receiver (Altera application note 254, figure 3 on page 5 > > http://www.altera.com/literature/an/an254.pdf ). > > But I need a transreceiver. Should I use same connection as with > > transmitter or something else? Or is only way to have transmitter and > > receiver pins & resistors and then connect them to together? > > > > Thank you for your help! > > > > - JRArticle: 54913
Sounds about right. I almost fell out of my chair when I saw the list pricing... Whew... "rAinStorms" <chris_karma@xtra.co.nz> wrote in message news:<zsYoa.16904$mZ4.194067@news.xtra.co.nz>... > I work for a volume manufacturer using 1C6. > > Take your price below and * 1/3 would be more accurate. > > I am interested in watching what Xilinx are going to do to compete. > > Cheers. > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:3E9F6D62.B9B9BC2B@yahoo.com... > > Steve Knapp wrote: > > > > Xilinx LUT+FF pairs Altera LEs > > * XC2S50E 1,536 $ 16.61 > > * XC2S100E 2,400 $ 24.47 EP1C3 2,910 $16.60 (T144) > > * XC2S150E 3,456 $ 26.84 EP1C4 4,000 $??? > > * XC2S200E 4,704 $ 31.29 > > * XC2S300E 6,144 $ 48.01 EP1C6 5,980 $33.20 > > * XC2S400E 9,600 $ 91.52 EP1C12 12,060 $87.00 > > > > * XC2S600E 13,824 $152.90 EP1C20 20,060 $222.00 > > (FG456) (FT400) > >Article: 54914
Hi Avrum Thank you for your very helpful advice. I have one further question. What is the difference between feeding the output of a DCM via an OBUF to a pad, and feeding it from a DCM to a DDR IOB flop and then through an OBUF to a pad? Many thanks Sam "Avrum" <avrum@REMOVEsympatico.ca> wrote in message news:<aHpoa.6292$f34.1102816@news20.bellglobal.com>... > Using the FPGA to generate multiple clocks is almost certainly the way to > go. However, since you are using Virtex-II devices, you don't need to > generate a 2x clock under normal circumstances; you can use the VII DDR IOB > flops to generate external copies of the clock for you. If you have your > 120MHz clock on a global clock buffer (call this clk120ext), then > instantiate two FDDRRSE elements > > FDDRRSE flop0 ( > .C0(clk120ext), > .C1(!clk120ext), // the FDDEESE has the ability to use the inverted clock > .CE(1'b1), > .D0(1'b1), > .D1(1'b0) > // Connect R and S as you see fit > ); > > Do the same for flop1 (you may need to fight with your synthesis tool to > prevent optimization from merging the two flops into one - set_dont_touch in > synopsys or syn_preserve in synplicity). Tie the Q outputs to the I of OBUFs > of the appropriate type, and lock them to two nearby IOBs, and you have > created two very low skew clock outputs. Furthermore, you can use the same > clock to generate the control signals going to the RAMs - if the load on the > clock and the control lines is identical, the arrival time of the control > signals at the RAMs will be nearly identical to the arrival of the clock > (you can invert the clock in the FDDRSE by flipping the values of D0 and D1 > in the instantiations if you want the control changes to take place around > the falling edge of the clock). > > The duty cycle of the outgoing clock will be similar to clk120ext - if > clk120ext is generated by a DCM, then the duty cycle will be pretty close to > 50/50. > > If you want the external clock to be the same as the internal clock, then > you may need to do some additional things. Starting with the board clock > (clk120), connect that through an IBUFG (call this CLK120in) and connect it > to the CLKIN of a DCM. Then connect CLK0 of the DCM to a BUFG. The output of > this BUFG is clk120ext, which is used to drive the DDR flops described > above. Instead of just instantiating two FDDRRSE and OBUFs, instantiate > three. Connect the output of the third OBUF to another IBUFG pin (on the > board), and from there to the CLKFB of the DCM. Match the three PCB trace > lengths. This ensures that the clocks at the SRAMs are in phase with clk120 > (the clock coming into the FPGA). You can then use a second DCM to generate > another clock domain - connect clk120in to the CLKIN of the DCM, connect > CLK0 to a second BUFG, and connect the output of the BUFG (called clk120int) > to the CLKFB of the DCM. This will generate an internal clock (clk120int) > which is ALSO in phase with CLK120, which can be used to clock flip-flops > inside the device. > > The design of high speed RAM interfaces can be tricky, but the Virtex-II > architecture provides you with a lot of tools to design them well - > particularly the DDR flops, and the DCMs (including the fine phase shift of > the DCM). You don't mention what kind of RAM you are using; Xilinx has > several appnotes about using Virtex-II devices with different types of > synchronous memories. > > Avrum > > "Hal Murray" <hmurray@suespammers.org> wrote in message > news:v9uikqh1ec8f6@corp.supernews.com... > > One approach to consider. The idea is to avoid the external > > clock buffer by generating several copies of the clock in > > the Xilinx. > > > > Make a 240 MHz clock. Use that to make a 120 MHz sq wave, and > > feed that to several nearby IOBs. Nearby is to reduce skew, > > so you want them all on the same clock line. I think that > > constrains you to left or right side rather than top or bottom. > > You would need to check the final routing carefully. > > > > You might be able to do something similar by connecting several > > OBUFs (rather than one) to the output of the DCM. You just need > > a way to make sure the skew between them is low. > > > > -- > > The suespammers.org mail server is located in California. So are all my > > other mailboxes. Please do not send unsolicited bulk e-mail or > unsolicited > > commercial e-mail to my suespammers.org address or any of my other > addresses. > > These are my opinions, not necessarily my employer's. I hate spam. > >Article: 54915
Hi, "B. Joshua Rosen" a écrit : > Why should Xilinx support a broken OS like Win98 when Microsoft no longer > supports it? If you feel compelled to use a Microsoft OS then use a > current version like XP or 2K. Are you sure that Microsoft is no longer supporting Win98 ? Please visit : http://www.microsoft.com/windows98/ Very interresting !!! ;*D Thierry. -- Regards. Equip'Trans http://www.equiptrans.com/Article: 54916
look for dokumentation of "Parallel cable III" or "DLC5" download cable schematic at Xilinx. With this hardware and free available iMPACT software (included in ISE, can run under command line) You can program xc95xx easily. Peter "Ian Stirling" <root@mauve.demon.co.uk> schrieb im Newsbeitrag news:b81co1$9is$1$830fa17d@news.demon.co.uk... > I can find brief datasheets listing pinouts. > Are there any more detailed specs on how to take an image of the chip, and > upload it? > For ISP, by the end user, where a programming device will not be available. > > -- > http://inquisitor.i.am/ | mailto:inquisitor@i.am | Ian Stirling. > ---------------------------+-------------------------+-------------------- ------ > "The theory of everything falls out trivially." -- Etherman, sci.physics kook.Article: 54917
I am saying that as a volume manufacturer we have not yet seen Xilinx "come to the table" on the new volume price breaks avaiable. I am sure they will ... if the they live up to their press in the near future. You cant relate low volume un negotiated pricing to those of high volume manufacture. You cannot also guage any reasonable comparison as there are so many factors you cant account for. The table presented did that it seemed. Cheers. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3EA458BA.D1464A40@yahoo.com... > rAinStorms wrote: > > > > I work for a volume manufacturer using 1C6. > > > > Take your price below and * 1/3 would be more accurate. > > > > I am interested in watching what Xilinx are going to do to compete. > > I don't understand what you are saying. Are you saying that Altera > sells their parts in volume for a third the price listed below and > Xilinx doesn't? It has always been my understanding that you can get > significant price reductions from nearly *any* chip maker if you are > using large quantities. Why would Xilinx be any different? > > I am quite certain that Altera was looking at a Xilinx Spartan II price > sheet when they set the Cyclone *list* prices. The real price for > quantities *always* depends on their real costs of manufacture, or even > their *future* cost of manufacture. They can take a loss on the parts > now knowing that they will be able to get their production costs down > over the life of *your* product and end up turning a profit. Of if > nothing else they will even buy a socket to keep the competition out of > your shop! But this is all based on volume. > > -- > > 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: 54918
Hi, As we plan to use Quartus on Linux, please, could you give me your opinion about your experience of quartus2.2 ? What about the chip programming ? And about SoPC builder ? How does it work with nios-run and so on ? Do you still have to use kind of special shell or can you use your standard shell ? Do you know if Quartus 2.2 works with Mandrake 9.1 ? If it's not ready to use, what could be done to make it work ? Greetings Stéphane ManciniArticle: 54919
Dear colleagues, I have Xilinx virtex2-1000 and Textronix Logic Analyzer. The problem is = the TTL output level from my logic analyzer is 3.8 volt and the maximum = volatge to my Virtex2 is 3.3 volt. What is the common practice method to solve this problem ? If I add resistor, how to calculate the resistor value ? Thank you. Best regards, Basuki KerenArticle: 54920
Hi Steven. If, as you said, > At the low end of the density range, packaging and test costs dominate > the end-user price. Then: Why there is no some block RAM/multipliers and DCMs in the XC3S50? Why did Xilinx make the Spartan-3 "ugly duck"? I work for a design house (hardware and firmware), and in almost all our designs we use FPGAs and need memory blocks. Yes, I live in Brazil, and I know BP&M, but I´d like to talk to the child´s parents! (I'm not used write in English. Please, forgive my mistakes.) Luiz Carlos Oenning Martins KHOMP SolutionsArticle: 54921
Check if you have all the files (edifs in your case I think) in the project directory Aurash paraag wrote: > when i Translate my top level code i get this type of an error > > ERROR:NgdBuild:604 - logical block 'filtercore' with type 'mac_fir' could not be > resolved. A pin name misspelling can cause this, a missing edif or ngc file, > or the misspelling of a type name. Symbol 'mac_fir' is not supported in > target 'virtex'. > > can anyone tell me what it is???/ > > thanks paraag -- __ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324Article: 54922
"Mancini Stéphane" <stephane.mancini@inpg.fr> writes: > As we plan to use Quartus on Linux, please, could you give me your opinion > about your experience of quartus2.2 ? The only problem I have experienced is some zombie processes left by quartus. These can be killed using killall -9 quartus_cmd or whatever. I use Synopsys VCS and DC for simulation and synthesis so I can't speak for the Qaurtus simulator and synthesis tool. Altera seems to be moving in the right direction with respect to Tcl scripting. We run most of the place and route jobs using Tcl scripts. > What about the chip programming ? The only supported programmer is the serial byteblaster (correct me if I'm wrong). However, I would suggest using ISP if you have some other interface like PCI or Ethernet in your design. I've been doing programming using tftp from Linux to the NIOS development board. This works like a charm and only takes a second. This means you need an Ethernet interface as well as NIOS (or similar) on your board. > And about SoPC builder ? How does it work with nios-run and so on ? Do you SOPC builder is not supported under Linux. Even though it's a Java program and you can start it but I get problems when it's trying to run the bundled perl installation. SOPC builder will be supported in a (near?) future version of SOPC. > still have to use kind of special shell or can you use your standard > shell ? Under solaris you use a standard shell. I would assume you do the same under Linux. > Do you know if Quartus 2.2 works with Mandrake 9.1 ? > If it's not ready to use, what could be done to make it work ? I don't know. I use Red Hat 7.1 (what Altera has qualified) and Slackware 7.1. I would be surprised if it does not work under Mandrake. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 54923
Hi, I would like to know if there is a way to put initial values to internal RAM defined in VHDL. I'm not using technological primitives. I'm using Quartus 2 as synthesis tool. Thanks Stein KArticle: 54924
Taking the CLK0 (or any other output) of the DCM to an OBUF forces the signal to be routed in general routing. While it may be possible to place some kind of constraint on this path to limit the variability of this route, the timing of this path will change each time you re-run place and route. Also, running the output to TWO OBUFs can result in significant timing differences in the arrival at the two different OBUFs; each connection can take a completely different path in the general routing resources of the FPGA. Taking the CLK0 through a BUFG to the VII DDR IOB flop uses the dedicated clock distribution network within the device to get the clock to the flop. This clock network is hard wired, and carefully designed by Xilinx to insure that the arrival time of the clock at every flip-flop in the device is tightly controlled. Thus - you will get exactly the same result on every place and route run - the arrival at two IOBs (particularly ones that are physically close to eachother) are VERY close together (you can figure out how close using the source synchronous information provided at the end of the data sheet) - the timing of this path (from the IBUFG through the DCM, the BUFG, the clock network, the IOB flop and the OBUF) is well known and specified by the parameter Tickofdcm in the datasheet. Avrum "Sam Duncan" <damn_spam2001@yahoo.co.uk> wrote in message news:5bae7a33.0304212358.6a083cc7@posting.google.com... > Hi Avrum > > Thank you for your very helpful advice. I have one further question. What > is the difference between feeding the output of a DCM via an OBUF to a pad, > and feeding it from a DCM to a DDR IOB flop and then through an OBUF to a > pad? > > Many thanks > > Sam > > "Avrum" <avrum@REMOVEsympatico.ca> wrote in message news:<aHpoa.6292$f34.1102816@news20.bellglobal.com>... > > Using the FPGA to generate multiple clocks is almost certainly the way to > > go. However, since you are using Virtex-II devices, you don't need to > > generate a 2x clock under normal circumstances; you can use the VII DDR IOB > > flops to generate external copies of the clock for you. If you have your > > 120MHz clock on a global clock buffer (call this clk120ext), then > > instantiate two FDDRRSE elements > > > > FDDRRSE flop0 ( > > .C0(clk120ext), > > .C1(!clk120ext), // the FDDEESE has the ability to use the inverted clock > > .CE(1'b1), > > .D0(1'b1), > > .D1(1'b0) > > // Connect R and S as you see fit > > ); > > > > Do the same for flop1 (you may need to fight with your synthesis tool to > > prevent optimization from merging the two flops into one - set_dont_touch in > > synopsys or syn_preserve in synplicity). Tie the Q outputs to the I of OBUFs > > of the appropriate type, and lock them to two nearby IOBs, and you have > > created two very low skew clock outputs. Furthermore, you can use the same > > clock to generate the control signals going to the RAMs - if the load on the > > clock and the control lines is identical, the arrival time of the control > > signals at the RAMs will be nearly identical to the arrival of the clock > > (you can invert the clock in the FDDRSE by flipping the values of D0 and D1 > > in the instantiations if you want the control changes to take place around > > the falling edge of the clock). > > > > The duty cycle of the outgoing clock will be similar to clk120ext - if > > clk120ext is generated by a DCM, then the duty cycle will be pretty close to > > 50/50. > > > > If you want the external clock to be the same as the internal clock, then > > you may need to do some additional things. Starting with the board clock > > (clk120), connect that through an IBUFG (call this CLK120in) and connect it > > to the CLKIN of a DCM. Then connect CLK0 of the DCM to a BUFG. The output of > > this BUFG is clk120ext, which is used to drive the DDR flops described > > above. Instead of just instantiating two FDDRRSE and OBUFs, instantiate > > three. Connect the output of the third OBUF to another IBUFG pin (on the > > board), and from there to the CLKFB of the DCM. Match the three PCB trace > > lengths. This ensures that the clocks at the SRAMs are in phase with clk120 > > (the clock coming into the FPGA). You can then use a second DCM to generate > > another clock domain - connect clk120in to the CLKIN of the DCM, connect > > CLK0 to a second BUFG, and connect the output of the BUFG (called clk120int) > > to the CLKFB of the DCM. This will generate an internal clock (clk120int) > > which is ALSO in phase with CLK120, which can be used to clock flip-flops > > inside the device. > > > > The design of high speed RAM interfaces can be tricky, but the Virtex-II > > architecture provides you with a lot of tools to design them well - > > particularly the DDR flops, and the DCMs (including the fine phase shift of > > the DCM). You don't mention what kind of RAM you are using; Xilinx has > > several appnotes about using Virtex-II devices with different types of > > synchronous memories. > > > > Avrum > > > > "Hal Murray" <hmurray@suespammers.org> wrote in message > > news:v9uikqh1ec8f6@corp.supernews.com... > > > One approach to consider. The idea is to avoid the external > > > clock buffer by generating several copies of the clock in > > > the Xilinx. > > > > > > Make a 240 MHz clock. Use that to make a 120 MHz sq wave, and > > > feed that to several nearby IOBs. Nearby is to reduce skew, > > > so you want them all on the same clock line. I think that > > > constrains you to left or right side rather than top or bottom. > > > You would need to check the final routing carefully. > > > > > > You might be able to do something similar by connecting several > > > OBUFs (rather than one) to the output of the DCM. You just need > > > a way to make sure the skew between them is low. > > > > > > -- > > > The suespammers.org mail server is located in California. So are all my > > > other mailboxes. Please do not send unsolicited bulk e-mail or > > unsolicited > > > commercial e-mail to my suespammers.org address or any of my other > > addresses. > > > These are my opinions, not necessarily my employer's. I hate spam. > > >
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