Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi all, I have a very peculiar problem with some digitally controlled impedance (DCI) inputs on a Virtex2 device: whenever I enable the DCI on the inputs the signal levels go way down, without DCI I see about 800 mV and with the DCI on about 200 mV. The IO standard is HSTL_I_18, this is a QDR Sram interface design. Another strange thing is that I only see this behavior on the XC2V8000 device, the XC2V4000 and XC2V6000 devices work fine on the same hardware!? Any suggestions? Thanks, --- jakabArticle: 82651
"Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> skrev i meddelandet news:1bhdikbazp.fsf@cs.nmsu.edu... > "Ulf Samuelsson" <ulf@NOSPAMatmel.com> writes: > > > > The basis of the patent is the "ARM Ltd discovery" that less code is better > > than more code. > > Code compression for RISC is mentioned already in the original RISC paper by > > Katevenis. > > Original RISC paper by Katevenis? While I was able to find a 1983 > paper by him, near as I can tell the original RISC paper is still the > one by Patterson amd Ditzel in 1980. > -- OK, but both preceeded the ARM chip and code compression for RISC is therefore not a new thing discovered by ARM Ltd. They base their Thumb patent on the claim that architectures have only been developed to increase the performance, not to reduce code size, and that they discovered the need for code space reduction for RISC. I believe that the width of datapaths has been driven mostly by the need to increase addressspace. If you do not accept the ARM claim, then the Thumb patent becomes really weak. > Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605 > Department of Computer Science FAX -- (505) 646-1002 > New Mexico State University http://www.cs.nmsu.edu/~pfeiffer -- Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57Article: 82652
Jakab, Check that the Vrp and Vrn reference resistors go to the right supply. A common mistake is to have the Vrp (pmos) resistor go to Vcco (wrong), instead of ground (right), and similar for the Vrn resistor which should go to Vcco (right), not ground (wrong) Be sure to actually measure the reference resistor value. Really tiny surface mount resistors are easy to get wrong: instead of 51 ohms, they may have placed 510 ohm resistors there! Seeing the markings requires a loupe or magnifying glass! Also check you have used the right Vrp and Vrn pins for that bank. I know that some devices have alternate Vrn, Vrp pins, which require that the software know which ones you are using. I do not think this affects the 2V8000 (only smaller parts in smaller packages). All the devices share the exact same cell for the DCI (layout), so there is nothing magic about the 2V8000. Austin jakab.tanko@gmail.com wrote: > Hi all, > > I have a very peculiar problem with some > digitally controlled impedance (DCI) inputs > on a Virtex2 device: whenever I enable the > DCI on the inputs the signal levels go way > down, without DCI I see about 800 mV and with > the DCI on about 200 mV. The IO standard is > HSTL_I_18, this is a QDR Sram interface design. > Another strange thing is that I only see this > behavior on the XC2V8000 device, the XC2V4000 > and XC2V6000 devices work fine on the same > hardware!? > Any suggestions? > Thanks, > --- > jakabArticle: 82653
I am a beginner in VHDL using Xilinx Project Navigator 5.2i to design
a 8-bit by 8-bit binary array divider, the maximum pad to pad delay
that the 'Text-based Post Place & Route Timing Report' showed for the
program below was found to be 77.233 ns (from m<1> to r8<0> and from
m<2> to r8<0>), but when the output port 'f' was removed from the
design, the maximum pad to pad delay increased to 85.713 ns (from m<0>
to r8<4>). The only reference to 'f' in the architecture is in line
number 29 as
"f <= r2(8) or r3(8) or r4(8) or r5(8) or r6(8) or r7(8) or r8(8);"
I was wondering how this increase in delay happened when a port was
removed.
Also, the maximum combinational delay estimate in the synthesis report
is and 130.499 ns from m<0> to q<0> (without the port 'f') and 130.598
ns from m<0> to f (with the port 'f').
The device family is Spartan2 and device is xc2s15, package is cs144,
speed grade is -6 and design flow is XST VHDL.
VHDL Program:
entity div16x82 is
port (d:in bit_vector(7 downto 0);
m:in bit_vector(7 downto 0);
q:out bit_vector(7 downto 0);
r8:inout bit_vector(8 downto 0);
f: out bit);
end div16x82;
entity d5 is
port(di,mi,bi,ci:in bit;
bo,ro:out bit);
end d5;
architecture arch5 of d5 is
begin
bo<=((not di)and mi)or((not di) and bi)or(mi and bi);
ro<=di xor((not ci)and(mi xor bi));
end arch5;
architecture X of div16x82 is
component d5
port(di,mi,bi,ci:in bit;
bo,ro:out bit);
end component;
signal r1,r2,r3,r4,r5,r6,r7,b1,b2,b3,b4,b5,b6,b7,b8:bit_vector(8
downto 0);
signal c:bit_vector(8 downto 0);
begin
f <= r2(8) or r3(8) or r4(8) or r5(8) or r6(8) or r7(8) or r8(8);
d10:d5 port map(d(7),m(0),'0',c(1),b1(0),r1(0));
d11:d5 port map('0',m(1),b1(0),c(1),b1(1),r1(1));
d12:d5 port map('0',m(2),b1(1),c(1),b1(2),r1(2));
d13:d5 port map('0',m(3),b1(2),c(1),b1(3),r1(3));
d14:d5 port map('0',m(4),b1(3),c(1),b1(4),r1(4));
d15:d5 port map('0',m(5),b1(4),c(1),b1(5),r1(5));
d16:d5 port map('0',m(6),b1(5),c(1),b1(6),r1(6));
d17:d5 port map('0',m(7),b1(6),c(1),b1(7),r1(7));
c(1)<=b1(7);
q(7)<= not b1(7);
d20:d5 port map(d(6),m(0),'0',c(2),b2(0),r2(0));
d21:d5 port map(r1(0),m(1),b2(0),c(2),b2(1),r2(1));
d22:d5 port map(r1(1),m(2),b2(1),c(2),b2(2),r2(2));
d23:d5 port map(r1(2),m(3),b2(2),c(2),b2(3),r2(3));
d24:d5 port map(r1(3),m(4),b2(3),c(2),b2(4),r2(4));
d25:d5 port map(r1(4),m(5),b2(4),c(2),b2(5),r2(5));
d26:d5 port map(r1(5),m(6),b2(5),c(2),b2(6),r2(6));
d27:d5 port map(r1(6),m(7),b2(6),c(2),b2(7),r2(7));
d28:d5 port map(r1(7),'0',b2(7),c(2),b2(8),r2(8));
c(2)<=b2(8);
q(6)<= not b2(8);
d30:d5 port map(d(5),m(0),'0',c(3),b3(0),r3(0));
d31:d5 port map(r2(0),m(1),b3(0),c(3),b3(1),r3(1));
d32:d5 port map(r2(1),m(2),b3(1),c(3),b3(2),r3(2));
d33:d5 port map(r2(2),m(3),b3(2),c(3),b3(3),r3(3));
d34:d5 port map(r2(3),m(4),b3(3),c(3),b3(4),r3(4));
d35:d5 port map(r2(4),m(5),b3(4),c(3),b3(5),r3(5));
d36:d5 port map(r2(5),m(6),b3(5),c(3),b3(6),r3(6));
d37:d5 port map(r2(6),m(7),b3(6),c(3),b3(7),r3(7));
d38:d5 port map(r2(7),'0',b3(7),c(3),b3(8),r3(8));
c(3)<=b3(8);
q(5)<= not b3(8);
d40:d5 port map(d(4),m(0),'0',c(4),b4(0),r4(0));
d41:d5 port map(r3(0),m(1),b4(0),c(4),b4(1),r4(1));
d42:d5 port map(r3(1),m(2),b4(1),c(4),b4(2),r4(2));
d43:d5 port map(r3(2),m(3),b4(2),c(4),b4(3),r4(3));
d44:d5 port map(r3(3),m(4),b4(3),c(4),b4(4),r4(4));
d45:d5 port map(r3(4),m(5),b4(4),c(4),b4(5),r4(5));
d46:d5 port map(r3(5),m(6),b4(5),c(4),b4(6),r4(6));
d47:d5 port map(r3(6),m(7),b4(6),c(4),b4(7),r4(7));
d48:d5 port map(r3(7),'0',b4(7),c(4),b4(8),r4(8));
c(4)<=b4(8);
q(4)<= not b4(8);
d50:d5 port map(d(3),m(0),'0',c(5),b5(0),r5(0));
d51:d5 port map(r4(0),m(1),b5(0),c(5),b5(1),r5(1));
d52:d5 port map(r4(1),m(2),b5(1),c(5),b5(2),r5(2));
d53:d5 port map(r4(2),m(3),b5(2),c(5),b5(3),r5(3));
d54:d5 port map(r4(3),m(4),b5(3),c(5),b5(4),r5(4));
d55:d5 port map(r4(4),m(5),b5(4),c(5),b5(5),r5(5));
d56:d5 port map(r4(5),m(6),b5(5),c(5),b5(6),r5(6));
d57:d5 port map(r4(6),m(7),b5(6),c(5),b5(7),r5(7));
d58:d5 port map(r4(7),'0',b5(7),c(5),b5(8),r5(8));
c(5)<=b5(8);
q(3)<= not b5(8);
d60:d5 port map(d(2),m(0),'0',c(6),b6(0),r6(0));
d61:d5 port map(r5(0),m(1),b6(0),c(6),b6(1),r6(1));
d62:d5 port map(r5(1),m(2),b6(1),c(6),b6(2),r6(2));
d63:d5 port map(r5(2),m(3),b6(2),c(6),b6(3),r6(3));
d64:d5 port map(r5(3),m(4),b6(3),c(6),b6(4),r6(4));
d65:d5 port map(r5(4),m(5),b6(4),c(6),b6(5),r6(5));
d66:d5 port map(r5(5),m(6),b6(5),c(6),b6(6),r6(6));
d67:d5 port map(r5(6),m(7),b6(6),c(6),b6(7),r6(7));
d68:d5 port map(r5(7),'0',b6(7),c(6),b6(8),r6(8));
c(6)<=b6(8);
q(2)<= not b6(8);
d70:d5 port map(d(1),m(0),'0',c(7),b7(0),r7(0));
d71:d5 port map(r6(0),m(1),b7(0),c(7),b7(1),r7(1));
d72:d5 port map(r6(1),m(2),b7(1),c(7),b7(2),r7(2));
d73:d5 port map(r6(2),m(3),b7(2),c(7),b7(3),r7(3));
d74:d5 port map(r6(3),m(4),b7(3),c(7),b7(4),r7(4));
d75:d5 port map(r6(4),m(5),b7(4),c(7),b7(5),r7(5));
d76:d5 port map(r6(5),m(6),b7(5),c(7),b7(6),r7(6));
d77:d5 port map(r6(6),m(7),b7(6),c(7),b7(7),r7(7));
d78:d5 port map(r6(7),'0',b7(7),c(7),b7(8),r7(8));
c(7)<=b7(8);
q(1)<= not b7(8);
d80:d5 port map(d(0),m(0),'0',c(8),b8(0),r8(0));
d81:d5 port map(r7(0),m(1),b8(0),c(8),b8(1),r8(1));
d82:d5 port map(r7(1),m(2),b8(1),c(8),b8(2),r8(2));
d83:d5 port map(r7(2),m(3),b8(2),c(8),b8(3),r8(3));
d84:d5 port map(r7(3),m(4),b8(3),c(8),b8(4),r8(4));
d85:d5 port map(r7(4),m(5),b8(4),c(8),b8(5),r8(5));
d86:d5 port map(r7(5),m(6),b8(5),c(8),b8(6),r8(6));
d87:d5 port map(r7(6),m(7),b8(6),c(8),b8(7),r8(7));
d88:d5 port map(r7(7),'0',b8(7),c(8),b8(8),r8(8));
c(8)<=b8(8);
q(0)<= not b8(8);
end X;
Article: 82654Hi to all, Just wondering if you could give me an idea of a current salary ballpark for the following details/person: Person: PhD in DSP on FPGA (3.5 years of RTL VHDL mainly for Xilinx and C++ development) 1st class honours degree in Software Development/Electronic & Electrical Engineering 1 years industry experience (+ some during PhD) sales training/experience extensive presentation writing/giving experience Job description: DSP on FPGA design in RTL VHDL on Xilinx/Altera/Lattice/Actel etc. C++ development Customer visits/application support Technical documentation/marketing material Presentations to customers/conferences/seminars Job Location: Please give an idea for Atlanta and San Jose Thanks very much in advance for your timeArticle: 82655
> Marc Randolphwrote: > Howdy, > > Yes, it should be possible. You'll probably pick up a little jitter, > and definitely will have a phase offset due to prop delay, but probably > nothing that is a show stopper. > > You didn't say if you need to clock I/O signals into the part with this > clock. Or out of the part. For the out direction, is there a > requirement that the I/O's toggle with a particular phase relationship > to the input clock? If you do have I/O requirements, I believe you can > work around it by using the fixed phase offset of the DCM to dial in a > compensation for the prop delay of the input buffer, internal routing > to the DCM, GBUF, and global clock delay - may take a few experiments > to get it right. I/O requirements are the toughest thing to meet with > a situation like yours, but at 100 MHz, it should be doable by locking > down the routing from the input IOB to the DCM(s). > > If you have lax or no I/O timing requirements, most of the above > doesn't apply and your job will be even easier. > > Good luck, > > Marc Hi Marc, Yes, I do need to clock IO signals in with this clock. The specific core I'm using is the PLB GEMAC, and the signal is gmii_rx_clk. Taking the naive approach and connecting the clock input to a DCM works...in that the device can send and receive packets successfully. However, if I add a peripheral to the OPB, the GEMAC stops working, and I'm led to believe that it only worked by chance in the first instance. The GEMAC data sheet is not terribly helpful I'm afraid (either that, or I'm not seeing the helpful data).Article: 82656
You might want to check the load as it may very well be that once your load increase the delay increase and your clock and data are no more meeting the timing requirements and hence the fail in the second case. Many time just inverting the clock solve the problem but you should check your timing report and don't forget of course you give the timing requirements, as you might need to use something in between and not as "drastic" as 180 Have Fun.Article: 82657
Mentre io pensavo ad una intro simpatica "Engineering Guy" scriveva: >> Hi all, >> I'm trying to test a filter I implemented with Xilinx ISE 6.1, so I >> created a testbench waveform. I'd like to import the input waveform from >> an ASCII file because the Pattern Generator can create only simple >> patterns. >> > Try something like this: [cut] Thanks, finally I found a solution very close to yours. -- Five out of four people have trouble with fractions. |\ | |HomePage : http://nem01.altervista.org | \|emesis |XPN (my nr): http://xpn.altervista.orgArticle: 82658
Hi Antti Lukats, > "vlsi_learner" <bajajk@gmail.com> schrieb im Newsbeitrag > news:1113563692.919736.183860@f14g2000cwb.googlegroups.com... >> could anyone please explain me the difference between the buffers IBUF >> OBUF BUFGP BUFGDLL BUFT etc available in XILINX FPGA. >> > RTFM Are you having a bad day? BenArticle: 82659
As others have pointed out, the manual does explain them. However, maybe more of what you are looking for is when to use them. This is all off the top of my head. My apologies for any minor inaccuracies. IBUF is the normal input buffer that connects an IOB from an input pin to the internal FPGA logic. IBUFG is the global input buffer. It is for the same purpose as IBUF except one uses it where one is connecting to a DCM or a BUFGMUX. This minimizes the skew of signals coming from off chip. For example, if your crystal is used by the FPGA and other devices on the board one would want the clock inside the FPGA to be as close to the clock outside the FPGA so that in the end your outputs of the FPGA are as close to the same clock edge as possible. If one is using clock feedback from the board IBUFG should also be used. OBUF is the opposite of the IBUF, connecting internal logic to an IOB for output. BUFG is one use of a BUFGMUX (see the appropriate FPGA user guide) and is used to distribute a signal inside the FPGA using the global nets to minimize skew inside the FPGA. BUFGs are generally used for clocks, resets, and signals where minimal skew is very important. If one is using a DCM and the output goes to more than one location, one probably should use a BUFG. BUFGP is a IBUFG followed by a BUFG. A BUFGP is used when one wants to distribute a signal across the FPGA with minimal skew and one is not using a DCM to do it. BUFGDLL is an IBUFG driving a CLKDLL. The CLKDLL is the primitives in Spartan II, Spartan IIe, Virtex, and Virtex-e prior to the DCM. BUFT is a tri-state buffer. This is used when one needs to implement tri-state. There are other buffers too, like IOBUF for bi-directional and xBUFDS for differential. If you let them, the ISE tools will take care of a lot of this buffering for you. Some thing like tri-state need to be taken care of by the user. EDK takes care of its own buffers if it is a top-level design and otherwise provides a stub to the user. This post is my own opinion, and not an official Xilinx post. Reverse domain and remove the NOSPAM from e-mail address to respond by e-mail. vlsi_learner wrote: > could anyone please explain me the difference between the buffers IBUF > OBUF BUFGP BUFGDLL BUFT etc available in XILINX FPGA.Article: 82660
"Ben Twijnstra" <btwijnstra@gmail.com> schrieb im Newsbeitrag news:erT7e.63478$Sc7.10321@amsnews05.chello.com... > Hi Antti Lukats, > > > "vlsi_learner" <bajajk@gmail.com> schrieb im Newsbeitrag > > news:1113563692.919736.183860@f14g2000cwb.googlegroups.com... > >> could anyone please explain me the difference between the buffers IBUF > >> OBUF BUFGP BUFGDLL BUFT etc available in XILINX FPGA. > >> > > RTFM > > Are you having a bad day? > > Ben YES. I wanted actually to appologizy to the OP, as my comment wasnt justified. Sorry. Antti PS Ben, I will reply to you separatly.Article: 82661
I've been following this newsgroup off and on for the last couple of years and I notice a steadily increasing amount of traffic here. The volume seems to be approaching that for various open source language forums/newsgroups thta I also follow. I'm curious: Any speculation as to the split between hobbyists and paid FPGA practicioners posting/lurking here? It would seem that with the advent of cheap FPGA prototyping boards, devices and free/semi-free design tools that a lot of hobbyists are trying out FPGAs. After all, you can get into FPGA design now for about the same or less money than it takes to get into Lego Mindstorms - which is just amazing when you think about it. Also, are there FPGA user's groups springing up out there? I'm thinking of starting one here in Portland, OR. Any interest? PhilArticle: 82662
ALuPin wrote: > > When performing a functional simulation with Modelsim > Sdram_csn gets "10" at a certain point. (Reset: Sdram_csn="11") > > The Timing Simulation with Modelsim instead shows that > Sdram_csn gets "11". The very first thing you should do when you get a function <-> gate mismatch is to go back to your static timing analysis report and verify that there are no timing violations reported. The second thing is to verify that your testbench meets the setup & hold requirements for the "real" part. This applies both to outputs from the tb and inputs to it. The third thing is to make sure that any combinational processes in your RTL have *all* of the input signals in the sensitivity list. This will take care of 99.9% of mismatches. Any remaining issues will be the proverbial 5% that takes 95% of the time. :( -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.comArticle: 82663
I'd imagine most people here are employed, consultants, small business, occasional blue chip EEs etc beside the FPGA vendor reps. The traffic reflects the niggling details that make simple things harder than 1st seems and a little ragging on the vendors to boot. Not sure if open source is of that much interest here except to the entry level or for educational purposes. The free semi free tools are a great way for vendors to rope in new paying customers perhaps a future woz or 2 will give them larger order, no OSS agenda here. Since FPGAs are heading up into low end ASIC territory, not sure if hobbyists will become a major deal here, mostly serious hobyists are perhaps buddying engineers. It may seem as if FPGAs are a little reminiscant of the 70s computer clubs but I don't expect to see homebrew clubs popping up. regards johnjakson at usa dot comArticle: 82664
As someone in the Porland area, as much as I love FPGA work I doubt I'd find much to "share" at a users' group. I have seen what appears to be a larger base of less informed people posting here asking questions that appear they're 1) coming to FPGAs from a non-hardware background without assistance or 2) they don't have the first idea of the architectures they're targeting as if they don't know where to begin looking for backround information. A users' group might help those who don't have a clue but I'd hate to have a clue and not be able to get much from the meetings outside of invitations for beer. What is a hobbyist but someone trying to do the job of a professional with roughly the same tools? - John_H "Phil Tomson" <ptkwt@aracnet.com> wrote in message news:d3p8ng01f0i@enews2.newsguy.com... > I've been following this newsgroup off and on for the last couple of years > and I notice a steadily increasing amount of traffic here. The volume > seems to be approaching that for various open source language > forums/newsgroups thta I also follow. > > I'm curious: > Any speculation as to the split between hobbyists and paid FPGA > practicioners posting/lurking here? > > It would seem that with the advent of cheap FPGA prototyping boards, > devices and free/semi-free design tools that a lot of hobbyists are trying > out FPGAs. After all, you can get into FPGA design now for about the same > or less money than it takes to get into Lego Mindstorms - which is just > amazing when you think about it. > > Also, are there FPGA user's groups springing up out there? I'm thinking > of starting one here in Portland, OR. Any interest? > > Phil >Article: 82665
> Writing a VHDL model of a CPU is the closest to designing my own CPU > I'll ever get. There is something exciting about that!!!! Er, that is designing a CPU! Probably the large majority of commerical CPUs are synthesizable, or contain a lot of synthesizable code. Cheers, JonArticle: 82666
hi, I want to input data from outside the board to the microblaze.can i do it using uart in my design?Can i make this data come from the hyperterminal to the uart and from uart to microblaze?In such a system what ever output microblaze sends outside the board can come on the hyperterminal.Can this output data go to a file? ThanxArticle: 82667
Hi, This is a slightly off topic question. I have been following this discussion about the new ISE 7.1. Before it got released I remember there was some talk about that the GUI would be based on a new GUI library, not the WINDU stuff anymore. After it got released I did not find any talk about that anymore, maybe I overlooked something. Did it really got changed or is 7.1 still using the WINDU stuff? If it got changed, what GUI library is it now based on? Thanks for the information. GuenterArticle: 82668
Antti Lukats wrote: > Hi (hai means "shark" in my native language) > > 1 your question doesnt have an answer. > 2 and your assumptions are not correct. > 3 and if you keep using an identy like "teen" what hardly is your name and > wording in style 'Hai', 'plz' then you hardly will get answers to anything > you ask. If you dont understand what I mean then it would be of benefit for > you to go back to school and learn there something. > 4 if you do not get upset to what I said above and do some homework then you > will be able to correct your wrong assumptions and answer your question > yourself. > Hey Antti, Don't beat about the bush, man - tell him what you think, straight up! This softly-softly approach never works [grin] [Not to say that I don't agree with your points on the language though :-] Simon. > "teen" <nkishorebabu123@yahoo.com> schrieb im Newsbeitrag > news:1113544130.628433.67240@o13g2000cwo.googlegroups.com... > >>Hai all, >> I heard that the SOFT CPU's have wide range of benefits than >>the HARD CPU's. if so, then why still HARD CPU's are preferred. >> >>plz let me know the answer. >> >>regards, >>kishore >> > > >Article: 82669
Guenter Dannoritzer <dan_nospam_noritzer@web.de> writes: > I have been following this discussion about the new ISE 7.1. Before it > got released I remember there was some talk about that the GUI would > be based on a new GUI library, not the WINDU stuff anymore. [...] > Did it really got changed or is 7.1 still using the WINDU stuff? AFAICT, ISE 7.1i on Linux still uses Wind/U. It doesn't seem likely that Webpack 7.1i would differ in that regard. I don't particularly care what toolkit they use as long as the Linux hosted product works reasonably well.Article: 82670
JJ wrote: > I'd imagine most people here are employed, consultants, small business, > occasional blue chip EEs etc beside the FPGA vendor reps. The traffic > reflects the niggling details that make simple things harder than 1st > seems and a little ragging on the vendors to boot. Not sure if open > source is of that much interest here except to the entry level or for > educational purposes. > > The free semi free tools are a great way for vendors to rope in new > paying customers perhaps a future woz or 2 will give them larger order, > no OSS agenda here. > > Since FPGAs are heading up into low end ASIC territory, not sure if > hobbyists will become a major deal here, mostly serious hobyists are > perhaps buddying engineers. It may seem as if FPGAs are a little > reminiscant of the 70s computer clubs but I don't expect to see > homebrew clubs popping up. Well, I'm a hobbyist. It makes a change from coding software for a living, at least when I can fit it in :-) The problems for hobbyists aren't really the vendors, or the tools, or even the large quantities of relatively domain-specific knowledge required. It's getting to grips with the teeny-weeny-pin soldering issues (at least it is for me). That's when you can get the parts in home-solderable form at all, eg: largest S3 is a PQ208. Whoosh. By the time you've added memory and a few peripherals, you're seriously out of pins :-( *And* it's a bitch to solder... Yes, I know there are good reasons (trust me - this is me being understanding :-) You really don't want to hear me whining about something :-)) Question though - would pin-grid array have the same signal integrity issues as BGA ? Or is it a function of lead-length rather than pin geography ? At least PGAs are solderable... I don't really expect A,X,whoever to produce parts that help the hobbyist, but it's immensely frustrating to get a quote of $350/board (inc. assembly/x-ray testing) when the part is "under 10$", well ok, $50 in my quantities... It's actually cheaper to buy a development board for deployment (eg: AVNET virtex-4 FX-12 board) as well as development, which is a bit weird really! Simon.Article: 82671
In article <1113602844.641997.77180@z14g2000cwz.googlegroups.com>, JJ <johnjakson@yahoo.com> wrote: >I'd imagine most people here are employed, consultants, small business, >occasional blue chip EEs etc beside the FPGA vendor reps. The traffic >reflects the niggling details that make simple things harder than 1st >seems and a little ragging on the vendors to boot. Not sure if open >source is of that much interest here except to the entry level or for >educational purposes. Well, there are some pretty good open source development tools out there like Icarus Verilog and GHDL (I've been using GHDL a lot lately with some pretty good results - it seems to be a very promising open source VHDL simulator). Mostly these are going to be frontend tools (like simulators) of course since most of the backend is proprietary. > >The free semi free tools are a great way for vendors to rope in new >paying customers perhaps a future woz or 2 will give them larger order, >no OSS agenda here. > >Since FPGAs are heading up into low end ASIC territory, not sure if >hobbyists will become a major deal here, mostly serious hobyists are >perhaps buddying engineers. It may seem as if FPGAs are a little >reminiscant of the 70s computer clubs but I don't expect to see >homebrew clubs popping up. I'm not so sure. I'm sort of in between being a hobbyist and a professional. I was involved in ASICs years ago and used some of the early Altera parts which would probably be categorized as CPLDs now. I moved on to EDA Software development and got away from the hardware end of things. Now I'm finding I want to tinker with FPGAs and since you can buy a Xilinx board for $99 that has a 200,000 equivilent gate part on it - well, that's pretty cool (the first ASIC I did back in the late 80's only had 2000 gates). I've also talked to a few people from the newsgroup here who are mainly hobbyists. Hardware 'hacking' sort of died there for a while when the barrier to entry was too high, but now it would seem to be making a comeback although the soldering irons and wirewrap boards are mostly gone replaced by simulators and synthesis tools like Xilinx's ISE Webpack. There's also the popularity of O'Reilly's new Make magazine which is full of hardware projects. PhilArticle: 82672
In article <3eX7e.32$f33.399@news-west.eli.net>, John_H <johnhandwork@mail.com> wrote: >As someone in the Porland area, as much as I love FPGA work I doubt I'd find >much to "share" at a users' group. > >I have seen what appears to be a larger base of less informed people posting >here asking questions that appear they're 1) coming to FPGAs from a >non-hardware background without assistance or 2) they don't have the first >idea of the architectures they're targeting as if they don't know where to >begin looking for backround information. A users' group might help those >who don't have a clue but I'd hate to have a clue and not be able to get >much from the meetings outside of invitations for beer. Well, you could be the seasoned professional offering nuggets of hardware engineering wisdom - a guru :) The other thing that User's groups do is to help spread ideas, memes and idioms. I'm involved in a user's group for the Ruby programming language, for example, and most of us know Ruby pretty well, but it's great when someone comes in and does a presentation and I sit back and think "Wow, I didn't know you could do that!". It's also great when someone comes in with an idea for something to develop and we start trying it out right there in the meeting. > >What is a hobbyist but someone trying to do the job of a professional with >roughly the same tools? Well, much cheaper tools anyway ;-) I can't afford ModelSim, but I can download and compile Icarus or GHDL (both open source) for all of my HDL simulation needs. Are they as slick as ModelSim? No, but they're actually pretty capable and I get things done with them. PhilArticle: 82673
downunder wrote: > Yes, I do need to clock IO signals in with this clock. The specific > core I'm using is the PLB GEMAC, and the signal is gmii_rx_clk. > Taking the naive approach and connecting the clock input to a DCM > works...in that the device can send and receive packets successfully. > However, if I add a peripheral to the OPB, the GEMAC stops working, > and I'm led to believe that it only worked by chance in the first > instance. The GEMAC data sheet is not terribly helpful I'm afraid > (either that, or I'm not seeing the helpful data). Ah, now I better understand what you're trying to do. I would have to agree with you that the GEMAC "data sheet", at least that I have access to, is suprisingly brief and lacking of detail. I suppose they are expecting that you'll just take their source and use it, no questions asked. Anyway, back to your clock problem. The two global clocks that the GEMAC core says it needs are almost certainly the rx clock from the GMII device and a main reference clock - and it almost certainly assumes those global clocks come in on GCLK pins. Since yours doesn't, you'll probably need to try to come close to duplicating the IBUFG -> BUFG prop delay with your path: IBUF -> chip routing -> DCM -> BUFG You can do that by using the fixed or variable phase offset of the DCM to dial in a delay that compensates for your overly lagged clock network. The only problem with the routing to the DCM is that you need to nail it down so that the delay doesn't change every other build - look into using directed routing for that. Once you have that locked down, you can go about moving the clock around with the DCM so that it's output is lined up with where it needs to be (may take some trial, error, and patience). You might even be able to use the "working" version of your design to get some idea of what the clock phase should be - you can bring the clock out using a DDR flop... this will give you external visability of the clock phase with relation to the input clock phase. Have fun, MarcArticle: 82674
Eric wrote: > Cost!!!! > > That is the main reason why Hard CPU's are still used. They are > cheaper.... a Phillips Arm 7 32 bit CPU is about $3.50 in quantity. An > FPGA with a similar size softcpu like a Microblaze is about $10. > > Soft CPU's are used for performance. They take advantage of the FPGA's > logic and use parallelizm to speed up operatiations (ie multipuly two > 32 bit numbers in a single clk cycle). A hard CPU would take 4 or more > clk cycles to multiply two 32bit numbers. > > So SoftCPU's used with FPGA logic can have a higher performance than an > equivelent hardCPU. True enough, but it seems to me an external (or on-chip) hard CPU loosely coupled with a "coprocessor" built of FPGA fabric gives you the best of both worlds for performance/cost and also minimizes power and you don't need lots of address pins going into the FPGA. Jeff
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