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
hello, what about us in europe ? Erika In article <G9kc6.1332$23.181745@dfiatx1-snr1.gtei.net>, "Jan Gray" <jsgray@acm.org> wrote: > Yesterday's XtremeDSP Simulcast was excellent. Well, what do you know -- the > promised "...delicious plate ... of goodies ... " was not just hyperbole. > Here are some impressions and speculations. > > 1. We FMAP'ing/RLOC'ing dinosaurs shouldn't feel so bad. We may soon be > joined by the Verilog/VHDL dinosaurs. > > 2. There are a ton of compelling applications of 100K logic cells and 100s > of multipliers. Time to crack open a signal processing textbook. > > 3. With the new buffered programmable interconnect, that graph of number of > net loads, to ns delay, was pretty darn flat... > > 4. There were a couple of hints that there might be another tier of on-chip > RAM coming -- perhaps suitable for storing an entire frame. Great -- but > multiported, or at least multibanked would be nice -- and please, don't > count such a RAM as a zillion system gates. :-) > > 5. XCITE is awesome. I looked around our downlink site and 'most every > attendee was grinning and/or nodding (though not quite high-fiving). In some > circumstances you can even use the XCITE controlled impedance technology to > parallel terminate inputs from other unterminated drivers. > > 6. Erich Goetting, Xilinx VP, revealed the forthcoming Virtex-II with > PowerPC and multiple 3.125 Gbps links will be called Virtex-II Pro. > > 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye > diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to > interface to. > > 8. I loved the hypothetical (?) die layout diagram of a Virtex-II Pro part > with *four* embedded PowerPC cores. Coooool. Here I was thinking that soft > cores might be relevant as chip-multiprocessors > [http://www.fpgacpu.org/usenet/soft.html] -- but perhaps not if the world > embraces hard core chip-multiprocessors embedded in the programmable logic > fabric. > > Very nice work, Xilinxers! > > With a multi-hundred-million-transistor budget to play with, it will be > quite fascinating to see what Virtex-II 'immerses' next. I can think of > several interesting hard cores. > > Jan Gray, Gray Research LLC > FPGA CPU News: www.fpgacpu.org > > Sent via Deja.com http://www.deja.com/Article: 28876
Jan Gray wrote: > > Yesterday's XtremeDSP Simulcast was excellent. Well, what do you know -- the > promised "...delicious plate ... of goodies ... " was not just hyperbole. > Here are some impressions and speculations. > > 1. We FMAP'ing/RLOC'ing dinosaurs shouldn't feel so bad. We may soon be > joined by the Verilog/VHDL dinosaurs. ROTFL!!!! > > 2. There are a ton of compelling applications of 100K logic cells and 100s > of multipliers. Time to crack open a signal processing textbook. At least for the deep pocketed. I thought the multipliers were a little misrepresented. The data book indicates about 140 Mhz max for the 18x18. The 200+ numbers they were showing were for 4x4 and maybe the 8x8s. In the smaller devices, you don't have that many of them to play with. Still, a nice feature that will make hardware DSP applications more accessible to the systems and software DSP types. > > 3. With the new buffered programmable interconnect, that graph of number of > net loads, to ns delay, was pretty darn flat... The active interconnect is a definite plus. Plain Virtex is way too sensitive to loading, especially for control signals leading into carry chains using mux_ands. I don't remember the 4K loading as being nearly as sensitive. Hopefully this is NOT and excuse to do away with floorplanning once again. > > 4. There were a couple of hints that there might be another tier of on-chip > RAM coming -- perhaps suitable for storing an entire frame. Great -- but > multiported, or at least multibanked would be nice -- and please, don't > count such a RAM as a zillion system gates. :-) > > 5. XCITE is awesome. I looked around our downlink site and 'most every > attendee was grinning and/or nodding (though not quite high-fiving). In some > circumstances you can even use the XCITE controlled impedance technology to > parallel terminate inputs from other unterminated drivers. Yep, in fact people were more excited about this than the guy who won the bike at our location seemed to be about the winning the bike. This is a way cool feature, coming from a guy that is tired of explaining why his customer has to leave an area on the board larger than the chip for "stupid" resistors. > > 6. Erich Goetting, Xilinx VP, revealed the forthcoming Virtex-II with > PowerPC and multiple 3.125 Gbps links will be called Virtex-II Pro. > Erich looked like he was battling indigestion during his talk. I dunno why, it seems to be a solid product. Should we all empty out our pencil drawers of any spare Rolaids and send them to him? > 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye > diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to > interface to. Does anybody have details on the serial interface. Is there clock recovery built in, so maybe it can be used for HDTV? > > 8. I loved the hypothetical (?) die layout diagram of a Virtex-II Pro part > with *four* embedded PowerPC cores. Coooool. Here I was thinking that soft > cores might be relevant as chip-multiprocessors > [http://www.fpgacpu.org/usenet/soft.html] -- but perhaps not if the world > embraces hard core chip-multiprocessors embedded in the programmable logic > fabric. > > Very nice work, Xilinxers! > > With a multi-hundred-million-transistor budget to play with, it will be > quite fascinating to see what Virtex-II 'immerses' next. I can think of > several interesting hard cores. > > Jan Gray, Gray Research LLC > FPGA CPU News: www.fpgacpu.org -- -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 or http://www.fpga-guru.comArticle: 28877
Rick Collins wrote:
>
> But now I want to do the same thing on the receive side where we need to
> use the bit vector on the left side and the byte vector on the right. So
> how do I do that without driving the compiler nuts?
>
> output [53*8-1:0] bar;
>
> reg[7:0] foo[1:13];
>
> always @(bar)
> for (j=1; j<14; j=j+1)
> bar[423-((13-j)*8):423-((13-j)*8)-7] <= foo[j];
>
> I can't do this, and I can't concatenate BAR into a byte. So am I only
> left with the original method of individual explicit byte assignments?
>
How about something like:
bar = {foo[1], foo[2], foo[3] .....
Paul Campbell
paul@verifarm.com
Article: 28878net9147@yahoo.com wrote: > > Vanted 6845 CGA crt controler in VHDL or etc... http://www.opencores.org/cores/crtc6845/ - ReinoudArticle: 28879
mrandelzhofer@my-deja.com writes: > I loved the old xact 6.xx fpga editor, which was originally better than > the neocad editor. > our team has done lots of successful xc3000/xc4003 designs just at the > chip level. Just like many people did successful programming at assembly language level. HLLs may be faster, but assembly level works. Same HDLs may be faster, but CLB level works. > now xilinx enhanced the fpga editor, and i'd like to experience some > small virtex designs just in the lowest design level. You look like a candidate for JBits, mail jbits@xilinx.com to order (free). Note that this is not an editor, but it is an Java library with an API to modify Virtex (and equivalent size Spartan-II) bitstreams CLB by CLB, feature by feature. That included bitstreams read direct from an powered up but not yet configured chips. So the default interface is Java code, but an graphical display and editor could be written. > (No doubt, the > high level design strategy is the more efficient way for higher > integrated devices). If you are prepared to take work time inefficiecy to experience low level control, you may contemplate taking JBits as base and buidling your ideal Virtex editor on top of it. This could even have an real-time on-line mode, where "open" reads out an chip and "save" writes the modification to an chip. JBits even allows run-time reloading of CLB columns. > - all the device specific stuff can be used, or used easier as in any > hdl. Only if the tool writer adds it. > but e.g. if you want access to all of the carry outputs of an alu in > vhdl, you can spend hours or days to find a solution. A.k.a. rope pushing. > also for testing in the lab, its often helpful to know everything about > the fpga-editor, so you don't need to recompile the design. Just load chip and modify. > an appnote about all these fpga pip, net, block, etc hackings would be > great ! It is in the JBits documentation. Actually just an intro and then an detailled list of all the parameters that can be inserted into the modifying functions. My JBits-docs-derived preliminary/partial CLB surrounding PIPs layout diagram sketch is at: http://neil.franklin.ch/Projects/PDP-10/Virtex-CLB-PIPs (You need an very wide browser window (or scroll horizontally), and an fixed width font for ASCII/plain text) -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng FH/BSc, Sysadmin, Roleplayer, LARPer, MysticArticle: 28880
Ray Andraka <ray@andraka.com> wrote: >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to >> interface to. > >Does anybody have details on the serial interface. Is there clock recovery >built in, so maybe it can be >used for HDTV? They have to have clock recovery. Putting just the IO cells just doesn't make any sense. It must come with CR and SER/DES to 8 or 16 bits so that you can manage the data at a reasonable speed. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 28881
Philip is of course correct in his explanation. But let me fill you in about the background. There is a reason why RAMs in general do not have a parallel reset: It is too expensive. It would add one extra transistor to each cell, plus a lot of connectivity. For that reason, there are (practically) no RAMs in the whole industry with a Reset input. Even our LUT-RAMs must be cleared sequentially. Global reset is not sequential, so it cannot reset any LUT or BlockRAM. But, since configuration is a sequential operation, it is a golden opportunity to stuff any predefined information into LUTs and BlockRAMs. (There is a Reset pin in some BlockRAM library symbols, but that means: Reset the output latches, not the memory content) I thought this might clarify things. I find it beneficial when I know not only "what", but also "why"! Peter Alfke, Xilinx Applications ====================================== Philip Freidin wrote: > On Fri, 26 Jan 2001 11:39:30 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> > wrote: > >Hello experts; > > > >I have a question about block and distributed RAM in the Virtex. When using > >coregen, you can specify initial values for the memory. If not specified, > >for example when RAM is inferred in synthesis, the initial values are 0. My > >question is, under what conditions are those values loaded? > > > >- After configuration? Yes, I'm pretty sure of this. > > Yes, it is part of the configuration bitstream > > >- After a global reset using the startup block? I think so, but I'm not > >sure. > > No. initial state is no longer available. Will retain contents of RAM > prior to reset. > > >- After a non-global reset? Probably not, but again I don't know. > > No. Same reason and result. > > > > >Since Virtex came out, Xilinx has been recommending against use of the > >global reset logic. I'm wondering now if that doesn't affect initialisation > >of memory components. If I do require my memories to be re-initialised, > >could I simply hook up my reset line to a manually instantiated startup > >block, without changing any of my other logic? Or is it an all or nothing > >decision? > > > >Your input is appreciated! > > > >Regards, > >Jamie > > > > Philip Freidin > FliptronicsArticle: 28882
In response to the original question,
> >- After a global reset using the startup block? I think so, but I'm not
> >sure.
"Philip Freidin" wrote
> No. initial state is no longer available. Will retain contents of RAM
> prior to reset.
Hmm. Related issues/questions. Maybe dumb questions. Please correct me
where/if I'm wrong.
-----
Part 1: Pertaining to coming out of reset after configuration, and the
potential for initialized RAM corruption during DEASSERTION of GSR.
I understand that the GWE (global write enable) signal protects initialized
block RAMs and LUT RAMs both during configuration and when coming out of
configuration mode.
I understand that after configuration, the number of cycles that GWE and
also GSR remain asserted are determined by bitgen options.
I understand that since the GSR net DEASSERTION delay may be greater than
the clock period, some FFs may come out of set/reset before others.
I understand that if some FFs come out of set/reset before others, if care
is not taken, the logic that computes a WE could inadvertently enable a
garbage write to a RAM. Therefore it seems prudent to gate all WEs to
initialized RAMs with a FF that itself awaits the infamous user-implemented
several-cycle-delayed limited ("state machines only") synchronous reset to
complete.
Question 1. Right?
-----
Part 2: Pertaining to manually resetting the device by asserting GSR on the
STARTUP_VIRTEX block and the potential for intialized RAM corruption during
initial REASSERTION of GSR.
If, after some time (long after configuration), the GSR input to an
instantiated STARTUP_VIRTEX block is asserted, GSR is asserted throughout
the device, with the effect that the device is reset. All FFs and block RAM
output registers are set/reset as appropriate.
Question 2. While this GSR input is asserted (asserting the hidden GSR net
throughout the device), is the GWE hidden net also asserted?
Question 3. In light of Philip's statement, "...Will retain contents of RAM
prior to reset....", is it not the case that if the device is reset via the
GSR input to the STARTUP_VIRTEX block, the GSR net will be ASSERTED after
various delays at various FFs, and those FFs throughout the device will all
take their own sweet time setting/resetting, in any order, and if this
occurs near a clock edge, and if some of those FFs are combined in logic to
produce a WE signal for a BRAM or LUT RAM, that a write of random garbage to
the RAM will occur?
Question 4. Isn't it true that if you plan to depend upon your RAM not
getting overwritten during manual reset, you had better consider the worst
case of partial resetting of every subset of the FFs that feed logic that
feed WEs.
For example, if you gate all your WEs with an INITIALIZED flip-flop that is
several cycles delayed from the device coming out of configuration (as
described above), then it could well happen that during manual reset some
FFs are set/reset near a clock edge and before the INITIALIZED flip-flop is
reset...
Thanks for any comments.
Jan Gray, Gray Research LLC
Article: 28883p.s. Shouldn't GWE be called GWE# (e.g. global write inhibit)? Jan Gray, Gray Research LLCArticle: 28884
We will never forget "you in Europe". Note: The president of Xilinx is Belgian, the Master of Ceremonies was Indian, one of the technical heavies is Australian, the VP of Engineering has German parents, and yours truly has his roots in Germany and Sweden. We are a world-wide company. As an aside: My personal experience ( many times over the past 30 years) has been that it is difficult to attract competent UK engineers to attend such seminars. (I know that they exist in spades, even after we imported so many ) . Allegedly, management did not allow them to go. Attendance in France and Germany was often 2 to 5 times higher, ( and the same number in Israel ! ), and the Brits cannot really put the blame on a language problem... Hoping for a positive surprise this time around ( hint, hint: tell your colleagues and wake up your management). I am told we reached 3000 engineers in the US and Canada. That's roughly one in 100,000 of the population. Can we get 500 in the U.K.? I am ready to change my mind ! European cellular telephony claims to be well ahead of the US, and a good portion of this seminar deals with DSP in advanced cellular telephone systems ( and video enhancement and compression )... Peter ================================== erika_uk@my-deja.com wrote: > hello, > > what about us in europe ? > > Erika >Article: 28885
That is what one would assume, but that doesn't mean they did so...which is the reason I am asking. I'm anxious to see the details on the serial interface. I've already got applications where I could use it. Muzaffer Kal wrote: > > Ray Andraka <ray@andraka.com> wrote: > >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye > >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to > >> interface to. > > > >Does anybody have details on the serial interface. Is there clock recovery > >built in, so maybe it can be > >used for HDTV? > > They have to have clock recovery. Putting just the IO cells just > doesn't make any sense. It must come with CR and SER/DES to 8 or 16 > bits so that you can manage the data at a reasonable speed. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.com -- -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 or http://www.fpga-guru.comArticle: 28886
Ray Andraka wrote: > I thought the multipliers were a little misrepresented. The data book > indicates about 140 Mhz max for the 18x18. The 200+ numbers they were showing > were for 4x4 and maybe the 8x8s. There "vill be vaiss" to make it substantially faster. Also, the present speed files are deliberately quite conservative > > > > > 3. With the new buffered programmable interconnect, that graph of number of > > net loads, to ns delay, was pretty darn flat... > From the center of an XC2V500, you can reach every logic or RAM input in less than 1 ns. > > > Erich looked like he was battling indigestion during his talk. I dunno why, it > seems to be a solid product. Should we all empty out our pencil drawers of any > spare > Rolaids and send them to him? Yes, I have also seen him more lively. But it was his very own brand-new presentation, and he must have felt the impact of 3000 pairs of eyes on him. Facing four TV cameras simultaneously has a way of intimidating the best of us. We all took this event very seriously... > > > > 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye > > diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to > > interface to. > > Does anybody have details on the serial interface. Is there clock recovery > built in, so maybe it can be used for HDTV? of course, and yes! Be our guest. Peter AlfkeArticle: 28887
Stephen Williams wrote:
>
> always @(bar)
> for (j=1; j<14; j=j+1)
> foo[j] <= bar[423-((13-j)*8):423-((13-j)*8)-7];
>
> Nope.
>
> Part selects (that is, ranges of bits) must have constant indices in
> Verilog. Verilog 200? relaxes this constraint. An in addition, you
> cannot address single bits of vector arrays. Verilog 200? relaxes this
> restriction as well.
>
> However, for what you want to do, you can probably make more use of
> parameter expressions to make the unrolled version more manageable.
Thanks. I ended up using Paul's suggestion of using the loop index to
select individual bits of BAR and concatenating 8 of them into a byte.
Works ok and is a compromise of readability.
But now I want to do the same thing on the receive side where we need to
use the bit vector on the left side and the byte vector on the right. So
how do I do that without driving the compiler nuts?
output [53*8-1:0] bar;
reg[7:0] foo[1:13];
always @(bar)
for (j=1; j<14; j=j+1)
bar[423-((13-j)*8):423-((13-j)*8)-7] <= foo[j];
I can't do this, and I can't concatenate BAR into a byte. So am I only
left with the original method of individual explicit byte assignments?
--
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
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com
Article: 28888Peter Alfke wrote: > > Ray Andraka wrote: > > > I thought the multipliers were a little misrepresented. The data book > > indicates about 140 Mhz max for the 18x18. The 200+ numbers they were showing > > were for 4x4 and maybe the 8x8s. > > There "vill be vaiss" to make it substantially faster. > Also, the present speed files are deliberately quite conservative As expected. I sure hope those multipliers will go alot faster. I'd certainly like to see the numbers for the pipelined modes. > > > > > > > > > 3. With the new buffered programmable interconnect, that graph of number of > > > net loads, to ns delay, was pretty darn flat... > > > > From the center of an XC2V500, you can reach every logic or RAM input in less than > 1 ns. Now that's cookin! So it should be about 2ns across the die. How well do these numbers hold up on a full design? I've also heard that loading does not effect the delays as much as it did in Virtex. Any truth to that? > > > > > > > Erich looked like he was battling indigestion during his talk. I dunno why, it > > seems to be a solid product. Should we all empty out our pencil drawers of any > > spare > > Rolaids and send them to him? > > Yes, I have also seen him more lively. But it was his very own brand-new > presentation, and he must have felt the impact of 3000 pairs of eyes on him. > Facing four TV cameras simultaneously has a way of intimidating the best of us. We > all took this event very seriously... His presentation was good. It just seemed he wasn't quite himself. > > > > > > > > 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye > > > diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to > > > interface to. > > > > Does anybody have details on the serial interface. Is there clock recovery > > built in, so maybe it can be used for HDTV? > > of course, and yes! Be our guest. Good news. I expected that answer, but I hadn't seen it anywhere. > > Peter Alfke -- -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 or http://www.fpga-guru.comArticle: 28889
Paul Campbell wrote:
>
> Rick Collins wrote:
>
> >
> > But now I want to do the same thing on the receive side where we need to
> > use the bit vector on the left side and the byte vector on the right. So
> > how do I do that without driving the compiler nuts?
> >
> > output [53*8-1:0] bar;
> >
> > reg[7:0] foo[1:13];
> >
> > always @(bar)
> > for (j=1; j<14; j=j+1)
> > bar[423-((13-j)*8):423-((13-j)*8)-7] <= foo[j];
> >
> > I can't do this, and I can't concatenate BAR into a byte. So am I only
> > left with the original method of individual explicit byte assignments?
> >
>
> How about something like:
>
> bar = {foo[1], foo[2], foo[3] .....
FOO is already a byte as shown above in the reg declaration. BAR is the
bit array.
I tried {bar[1],bar[2]...} <= foo[1]; and the compiler barfed. I guess
this is like VHDL where you can not use an agregate on the left side of
an equation (IIRC).
--
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
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com
Article: 28890If you follow the source for this technology down to www.hotrail.com it looks as if the key feature is quite a fancy clock recovery/centering scheme. "Ray Andraka" <ray@andraka.com> wrote in message news:3A725BAD.76940D93@andraka.com... > That is what one would assume, but that doesn't mean they did so...which is the > reason I am asking. I'm anxious to see the details on the serial interface. > I've already got applications where I could use it. > > > > Muzaffer Kal wrote: > > > > Ray Andraka <ray@andraka.com> wrote: > > >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye > > >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to > > >> interface to. > > > > > >Does anybody have details on the serial interface. Is there clock recovery > > >built in, so maybe it can be > > >used for HDTV? > > > > They have to have clock recovery. Putting just the IO cells just > > doesn't make any sense. It must come with CR and SER/DES to 8 or 16 > > bits so that you can manage the data at a reasonable speed.Article: 28891
On Thu, 25 Jan 2001 20:32:33 GMT, Newsbrowser@Newsbrowser.com (Newsbrowser) wrote: >This compilation takes a loooooooooooong time. > >It stalls at the compilation of a dual port 2048x12 sram. > >I have a feeling that this software is going through creating this >memory 1 cell at a time. It does, apparently after an earlier version made assumptions about inferring memory and could be caught out. I was told, at the time, they were going to fix it in a later release, but I'm not up to date on that. The other way, of course, is to black box the memory and use (Xilinx) CoreGen or (other) to instantiate it. When I do this, I have a wrapper around the memory (using Renoir) so that except at the lowest level of the hierarchy, the design is still technology independent. (And one can substitute the VHDL module for the black box, if desired) One of the guys (Stuart Clubb?) at their UK distributor, Saros Technology, http://www.saros.co.uk was preparing an app note about this. - BrianArticle: 28892
Yes the feedback I've gotten privately indicates that this is a very sexy interface, and very well planned. I can't wait to get my hands on one. Simon Bacon wrote: > > If you follow the source for this technology down to www.hotrail.com > it looks as if the key feature is quite a fancy clock recovery/centering > scheme. > > "Ray Andraka" <ray@andraka.com> wrote in message > news:3A725BAD.76940D93@andraka.com... > > That is what one would assume, but that doesn't mean they did > so...which is the > > reason I am asking. I'm anxious to see the details on the serial > interface. > > I've already got applications where I could use it. > > > > > > > > Muzaffer Kal wrote: > > > > > > Ray Andraka <ray@andraka.com> wrote: > > > >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice > eye > > > >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough > to > > > >> interface to. > > > > > > > >Does anybody have details on the serial interface. Is there clock > recovery > > > >built in, so maybe it can be > > > >used for HDTV? > > > > > > They have to have clock recovery. Putting just the IO cells just > > > doesn't make any sense. It must come with CR and SER/DES to 8 or 16 > > > bits so that you can manage the data at a reasonable speed. -- -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 or http://www.fpga-guru.comArticle: 28893
Is there an archived version of the XtremeDSP Simulcast available
online? I think many people would be interested in watching it, especially
with the rave reviews the event is getting.
-EKC
Jan Gray wrote in message ...
>Yesterday's XtremeDSP Simulcast was excellent. Well, what do you know --
the
Article: 28894Hi, I am student from Puerto Rico: We are trying to figure out how to implement an algorith that takes a 9*9 matrix (8 bits each element)and do a windowing of 5*5 in a column- wise and row-wise sliding and calculate for each 5*5 Moving-Window the Standard Deviation. Questions: 1. How do I handle the Squared Root of the SD? 2. And Which is better to implement on Xilinx XC4036 a floating-point or a fix-point approach for the results (another 9x9 matrix)? 3. I need to do a storage of those results: How do I configure the RAM resources for float-P or Fix-point? 4. Can you provide me good web resources to understand how to implement floating/fix point on FPGA? I hope to have some feedback on this regard, Javier Sent via Deja.com http://www.deja.com/Article: 28895
I am using the current version of Exemplar Leonardo (v20001b.106) and the 3.1i version of Xilinx Alliance... I have synthesized a design and produced an EDIF file. I am attempting to read this file via "ngdbuild" but errors are being reported with respect to the EQNs for the LUTs... In particular, it doesn't seem to like '!' in the equations... Here is an example: ERROR:NgdHelpers:403 - The EQN value of "((!I0*!I1*!I2*!I3))", on the LUT4 symbol "core_notri/mpu/cpu/ix408492", is not a valid equation. ERROR:NgdHelpers:404 - The above-referenced equation has the following error: Unexpected '!'. ERROR:NgdHelpers:403 - The EQN value of "((I0)+(!I3)+(!I1*!I2))", on the LUT4 symbol "core_notri/mpu/cpu/ix408493", is not a valid equation. ERROR:NgdHelpers:404 - The above-referenced equation has the following error: Unexpected '!'. I have also tried an older Alliance release with the same results. I have used this path before, using an older version of leonardo... Has something changed, or is there now some additional option that must be set that I have missed? Any ideas are welcome... Thanks, Ed HeplerArticle: 28896
In article <9503tg$rpj@vu-vlsi.ee.vill.edu>, Edward L. Hepler <elh@vu-vlsi.ee.vill.edu> wrote: >I am using the current version of Exemplar Leonardo (v20001b.106) >and the 3.1i version of Xilinx Alliance... > >I have synthesized a design and produced an EDIF file. > >I am attempting to read this file via "ngdbuild" but errors >are being reported with respect to the EQNs for the LUTs... > >In particular, it doesn't seem to like '!' in the equations... > >Here is an example: > >ERROR:NgdHelpers:403 - The EQN value of "((!I0*!I1*!I2*!I3))", on the LUT4 > symbol "core_notri/mpu/cpu/ix408492", is not a valid equation. >ERROR:NgdHelpers:404 - The above-referenced equation has the following error: > Unexpected '!'. >ERROR:NgdHelpers:403 - The EQN value of "((I0)+(!I3)+(!I1*!I2))", on the LUT4 > symbol "core_notri/mpu/cpu/ix408493", is not a valid equation. >ERROR:NgdHelpers:404 - The above-referenced equation has the following error: > Unexpected '!'. > > >I have also tried an older Alliance release with the same results. >I have used this path before, using an older version of leonardo... > >Has something changed, or is there now some additional option that >must be set that I have missed? > >Any ideas are welcome... > >Thanks, > >Ed Hepler > Sorry to bother everyone... I figured out that this time I did not use auto_write, but just wrote out the EDIF... This gave me some EDIF that was not Xilinx compatible... Thanks...Article: 28897
"JianyongNiu" <cop00jn@sheffield.ac.uk> wrote in message > My question is: where can I get the Virtex II Device Update CD? You don't need the Virtex-II Device Update CD unless you need Virtex-II support. However - if you have a valid software subscription with support for Virtex-II - you should have received the update CD in the mail by now. If not - I suggest you contact your local Xilinx representative and I'm confident they will be able to help. Rune BaeverrudArticle: 28898
Jan Gray wrote: > The last time I looked, the loadable binary counter CC16CLE unnecessarily > used two LUTs per bit. Xilinx should fix that. A straight adder should > also only need one LUT per bit. There may be hidden buffering or Hardware dependent limitations on the carry chain is my guess. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchukArticle: 28899
Hi, I am about to use an Actel A54SX32A in a FBGA144I package. I am interested in people having an experience with Actel's FPGAs and the best would be with the SX family. I have used up to know either Altera or Xilinx and I have no experience with Actel. Are there any known problems with these devices ? Anything specific to look at before starting a design ? Thank you in advance for your time and information. J.F. Hasson
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