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
I also have no major objections to BGA. For onesy-twosy customers we frequently make use of 3rd
party boards, trading perfect match for less development. Prototypes of stuff going into production
are sent out to contract assembly, often with the same shop that will be doing the full up assembly.
That said, it would be nice to have an option to significantly slow the edges (even the 2mA drive
has some pretty fast edges) to help with SI and EMI on those designs where I/O speed needn't be
really fast. I'm not sure what the implications from a chip design standpoint would be. If this
capability were available, then leaded packages wouldn't be the issue they are now with fast edges,
and you'd likely have a whole lot fewer SI cases to deal with.
Marc Randolph wrote:
> Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3DADEC2C.59DF33D0@xilinx.com>...
> > Marc (and all),
> >
> > Peter wandered by a few moments ago, and asked me why I was so against pq packages?
> >
> > I'm not, honestly!
> >
> > The Spartan family always has small and inexpensive packages for their parts.
>
> Howdy Austin,
>
> You're points are all valid, but I think the point of the two guys
> that originated this typic was that there are a few (perhaps too few?)
> customers that need some of the features of the V-II , but for some
> reason, feel they can't move to a BGA. That means they are stuck
> waiting for the top-of-the-line features to filter down to the Spartan
> family in a year or three.
>
> > Well, as it so happens, most places close to big technology centers have assembly services
> > just for prototyping! And it isn't that expensive! In fact, it costs a lot less than having
> > all of the stuff and people yourself, and not using it (which is what most prototyping
> > consists of: 5% building, and 95% debugging what was built). They do rework too.
> >
> > So ask around. Large assembly services sometimes have a small proto line just for this, and
> > in areas where there is a lot more business, there are small specialty shops that just do
> > proto runs.
> >
> > And I am talking here about five, two, and sometimes even one board for a reasonable price.
>
> In general, I agree with you that the cost of having a board assembled
> is rather inexpensive (probably less expensive than the original
> posters realize), especially if they were to include the cost of their
> own time assembling it rather than paying someone else.
>
> But you have to admit there are a few downsides:
>
> 1. Turn-around time
>
> 2. Correct assembly (even with perfect drawings, from time to time
> we'll have a few boards with assembly problem). Basicly, nobody is
> going to be as careful as you in assembling your boards. And if it
> *MUST* be correct the first time around (due to schedule, or can't
> afford to do it a second time), who are you going to trust?
>
> 3. Location (you point out that contract manufacturing/assembly works
> best when you're close to technology centers. If I'm not mistaken, at
> least one of the original posters was in Europe - where I'd expect
> contract manufacturing/assembly to cost considerably more than in the
> USA).
>
> 4. Cost
>
> Any one of these items is probably not overwhelming, but if the
> original posters had to face two or three of them, I wouldn't blame
> them for wanting to do the assembly themselves.
>
> Our boards are so complex, we don't have a choice but to contract it
> out.
>
> > Of course, you will have to learn how to assemble the kit of parts, and identify them, and
> > have a good schematic, and a good bill of materials, and have a good assembly drawing. All of
> > that you already have, right?
>
> My original response in this thread (about assembly and x-ray) was
> directed only at the other posters. We use contract manufacturing for
> everything, including reworking all but the simple packets. Our
> boards come back assembled and ready for testing (although they are
> habitually late by 3-5 days).
>
> This whole discussion is a really a product management discussion
> though (engineering could solve any of problems discussed in this
> thread). Is there enough PQFP volume to make it worth Xilinx's time
> to develop, document, make, stock, market, and sell that part? I'm
> guessing not (almost certainly based on customer survey), otherwise
> they would have already done it.
>
> Have fun,
>
> Marc
--
--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: 48426Thanks Jon, That does answer my question and help my understanding. I thought DSPs were powerful compared to what my design requirements were and it looks like they are. Thanks again, Prashant Jon Beniston <jbeniston@siroyan.com> wrote in message news:<3DAD5DA0.E94847EC@siroyan.com>... > Prashant wrote: > > > > Hi, > > > > I have a design which requires about 100 Million mulitplies and about > > 200 Million add/subtracts per second. I'm implementing my design in an > > FPGA. Does anyone have an idea how compute intensive is this design, > > if implemented in a DSP. I'm not sure how these operations would > > compare against MFLOPS or MIPS that DSP data sheets refer to. I would > > think my operations would be about 300 MIPS (mulitply + add). So a DSP > > claiming 300 MIPs or more of performance should be able to deal with > > this design. Am I right ? > > > > DSPs can do several multiply and accumulates (macs) in a single cycle. > For example, the company I work at will sell you a DSP that can do 16 > macs each cycle, which is 4 billion macs a second @ 250 MHz. I think > that would be more than adequate performance for your task. > > Cheers, > JonB > > > Thanks, > > PrashantArticle: 48427
Cordial saludo, Me complace presentar ante la comunidad de ingenieros, estudiantes y hobbystas de la electrónica digital, en especial a aquellos interesados en las áreas de diseño con Microcontroladores, FPGAs y DSPs el sitio web de SanJaaC Electronics (www.angelfire.com/electronic2/sanjaac, pronto www.sanjaac.com), una iniciativa de la ciudad de Medellín-COLOMBIA en la cual nos dedicamos al desarrollo de aplicaciones con este tipo de dispositivos. Desarrollamos sus aplicaciones según sus necesidades, y ofrecemos también equipos terminados. Igualmente desarrollamos herrmientas de desarrollo y equipos de instrumentación de bajo costo. Lo invitamos a que se ponga en contacto con nosotros. --------------- Good day, I am glad on introducing to the community of engineers, students and hobbysts of digital electronics, specially to those interested in Microcontroller/FPGA/DSP based designs, the web site of SanJaaC Electronics (www.angelfire.com/electronic2/sanjaac, soon www.sanjaac.com), a start-up from Medellín-COLOMBIA catering for applications develpment using such electronic devices. We are able to design applications following customer requeriments, and also we offer finished products. Besides that, we develop low cost development tools and instrumentation equipment. Please feel free to contact us. ---------------------------------------------------- Jaime Andrés Aranguren Cardona SanJaaC Electronics www.angelfire.com/electronic2/sanjaac sanjaac@lycos.com Electrónica Digital uC - FPGA - DSPArticle: 48428
"Sanjay Patil" <sanjay@cg-coreel.com> schrieb im Newsbeitrag news:aolr1m$nn5sm$1@ID-164436.news.dfncis.de... > Hello > I did that locking of pin > But Implementation could not be done. > I have attached the map report with this mail. The pin clk is not used as a clock pin (at least, the synthesizer doesnt identify clk as a clock pin inside you VHDL/Verilog) So it is just a normal input. So the synthesizer will use a IBUF (normal input buffer) for it, which cant be placed on a IBUFG site (the clock input pins) -- MfG FalkArticle: 48429
"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> schrieb im Newsbeitrag news:Z_or9.8019$Os6.1108829@news.xtra.co.nz... > Currently I have my eye on the XSA-50 from Xcess because it has a fpga and a > cpld and ram and flash > ( http://xess.com/prod027.php3) - What can you fit in a 50k gat FPGA - A > processor, memory controller, video and io support? > > A am also interested in FPSLIC but I understand you can only use the tools > for 4 months and then they cost many $$$$ after that Nowadays, Iwouldnt recommend anythink below 200k. Get a nice Spartan-II(E) with 200 or even 300k gates. They are cheap. www.nuhorizons.com (200k) www.burched.com (300k) The tools from Xilinx are free. Go for Webpack. -- MfG FalkArticle: 48430
The DLL ( Delay-Locked Loop) in Virtex and Spartan-II(E) can multiply by two. So you can use a 60 MHz external Xtal, double in the DLL, and then divide by 3 and 5 either in two DLLs or in the logic ( takes 2+3 flip-flops). With multiple, even with phase-related, clocks you must be careful whenever a signal crosses a clock boundary. DLLs can phase-align their outputs, but you still have to consider that 24 and 40 MHz sometimes do, and often do not change together. The safest bet, and my preferred solution, is to run everything off the common 120 MHz global clock, and control the flip-flops with CE. Might burn a bit more power, but is safe... Peter Alfke, Xilinx Applications. Jamie Morken wrote: > Hi, > > I'm working on a board that requires a 120MHz clock, a 24Mhz clock and a > 40MHz clock. > The board has a SpartanIIE device on it. I've never used a PLL (which the > Spartan device has) > so I'm unsure if I should use multiple crystals or if I can use the PLL to > give the needed frequencies. > > One of the IC's requires 24 MHz so would it be possible to use a 24MHz > crystal for this IC and also > feed the output to the FPGA to generate the 40 and 120 MHz clocks? > > cheers, > Jamie MorkenArticle: 48431
Sanjay, Make sure that you have an IBUFG as your input buffer for this net. If you've got the clock net connected to only clocks, most any synthesis tool will infer this for you, but I don't know your design nor your design entry method so I won't speculate why this didn't happen. So, if you're using schematic, drop down an IBUFG right after the input pad; if you're using an HDL, just instantiate the IBUFG right after your input port. You might also want to double-check that you've got a BUFG connected before the clock fans out as well (but after either a DLL or IBUFG). This is the buffer that you'll need to use in order to drive a high fanout net such that you'll probably have for this clock. This answer record might also be helpful for you in this case: http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10333 Best regards, Ryan Sanjay Patil wrote: > Hello > I did that locking of pin > But Implementation could not be done. > I have attached the map report with this mail. > > > Illegal physical site was the message. > > But pin#77 is a valid GCLK Pin for the Device(SEE MAP Report for details) > > Reply > Sanjay > > Here is the Map report: > > Release 4.2i - Map E.35 > Xilinx Mapping Report File for Design 'reg_4' > > Design Information > ------------------ > Command Line : map -p xc2s200-pq208-5 -cm area -k 4 -c 100 -tx off > reg_4.ngd > Target Device : x2s200 > Target Package : pq208 > Target Speed : -5 > Mapper Version : spartan2 -- $Revision: 1.58 $ > Mapped Date : Thu Oct 10 00:32:31 2002 > > Design Summary > -------------- > Number of errors : 1 > Number of warnings : 1 > > Section 1 - Errors > ------------------ > ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB > > component: > PAD symbol "clk" (Pad Signal = clk) > BUF symbol "clk_IBUF" (Output Signal = clk_IBUF) > Each of the following constraints specifies an illegal physical site for > a > > component of type IOB: > Symbol "clk" (LOC=P77) > Please correct the constraints accordingly > > > "S Embree" <sre3@duke.edu> wrote in message news:ee79989.1@WebX.sUN8CHnE... > >>If you want to use an external clock, you should use one of the dedicated > > global clock pins (GCK0, GCK1, etc.). Determine which GCK pin you want to > use and then lock your system clock to that pin using the .UCF file. > >Article: 48432
"Russell" <rjshaw@iprimus.com.au> schrieb im Newsbeitrag news:3DAD89F5.C7503D05@iprimus.com.au... > > There is a market vacuum for large scale fpgas in packages like pqfp144-240, > designed for low power, 5V tolerance, and because they're low power, they > should have slower edge rates. The edges should be deliberately slower or > adjustable to avoid ground-bounce. You can do a *lot* of dsp with an fpga > running at less than 50MHz. If there was such an fpga like this that could > only do 50MHz, i'd still buy them. Last i looked, the atmel at40k looked > interesting. Ah, but the tools weren't...easy to get or use. Open source? Sounds like a good fit for Spartan-II. -- MfG FalkArticle: 48433
"Tullio Grassi" <tullio@physics.umd.edu> schrieb im Newsbeitrag news:3DAE02D7.46A4ED12@physics.umd.edu... > the problem is that often also "so-called" professional companies > mess up with BGAs, without warning you :( > > Here : http://edg.umd.edu/heater/bga/ > is what happened to our BGAs. Shit happens. But what does this tell me? Not going to BGA because some companys are wanna-bees? -- MfG FalkArticle: 48434
--------------8B8147A5F6185E3D9991C697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marc, Well, I now undestand more of the issue. Thanks to all. Basically a lot of this comes from schools and universities, which are actually about 15 years behind the times. Even the most presitgious ones (and I won't name any names, as they are right here in the Bay Area) are unable to assemble or rework something as common as a cs144 package CPLD or FPGA. Of course, they are pretty lucky, as they can drive down the street and have their pick of twenty assembly houses that do short runs only. I would imagine that they could make a case for buying some up to date equipment, but given state budgets, and fund raising for private schools, perhaps this just isn't possible right now. There is a lot of equipment on the used market right now.....? It is quite sad, as here is the school that is supposed to be teaching the latest and greatest, and they still use wirewrap, and dip socketed chips ...... and nothing that the student sees after graduation will ever look like that. They miss out learning about signal integrity, 26 layer baords, solder thermal profiles, thermal management, jitter, etc etc. All really important stuff that takes a lot of work to get right. Now some of the graduate research stuff is up to date, but we need BSEE and MSEEs whoa re familiar with this stuff. Since I am a hobbiest, I also miss being able to work on a kit as home that could avail itself of the latest technologies. It was really tough to replace a SOIC 24 lead device with 75 mil centers when I soldered it in 180 degrees out at home with my solder pull-it remover, 25W needle tip iron, and dental pick! The kit with 14 and 16 pin DIPs is an easy thing to build, and one seldom sees surface mount parts of any kind in a kit (besides the fact that I can't see them anyway without glasses). There are a few outfits that sell the base board with the bga parts mounted, and you have to do all the rest, and I like that approach. Of course, we have the rework station here at work, and I could bring it in, and do what is needed here, but it just ain't the same thing! Austin "Always keep your hobbies from looking and feeling like work!" Marc Randolph wrote: > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3DADEC2C.59DF33D0@xilinx.com>... > > Marc (and all), > > > > Peter wandered by a few moments ago, and asked me why I was so against pq packages? > > > > I'm not, honestly! > > > > The Spartan family always has small and inexpensive packages for their parts. > > Howdy Austin, > > You're points are all valid, but I think the point of the two guys > that originated this typic was that there are a few (perhaps too few?) > customers that need some of the features of the V-II , but for some > reason, feel they can't move to a BGA. That means they are stuck > waiting for the top-of-the-line features to filter down to the Spartan > family in a year or three. > > > Well, as it so happens, most places close to big technology centers have assembly services > > just for prototyping! And it isn't that expensive! In fact, it costs a lot less than having > > all of the stuff and people yourself, and not using it (which is what most prototyping > > consists of: 5% building, and 95% debugging what was built). They do rework too. > > > > So ask around. Large assembly services sometimes have a small proto line just for this, and > > in areas where there is a lot more business, there are small specialty shops that just do > > proto runs. > > > > And I am talking here about five, two, and sometimes even one board for a reasonable price. > > In general, I agree with you that the cost of having a board assembled > is rather inexpensive (probably less expensive than the original > posters realize), especially if they were to include the cost of their > own time assembling it rather than paying someone else. > > But you have to admit there are a few downsides: > > 1. Turn-around time > > 2. Correct assembly (even with perfect drawings, from time to time > we'll have a few boards with assembly problem). Basicly, nobody is > going to be as careful as you in assembling your boards. And if it > *MUST* be correct the first time around (due to schedule, or can't > afford to do it a second time), who are you going to trust? > > 3. Location (you point out that contract manufacturing/assembly works > best when you're close to technology centers. If I'm not mistaken, at > least one of the original posters was in Europe - where I'd expect > contract manufacturing/assembly to cost considerably more than in the > USA). > > 4. Cost > > Any one of these items is probably not overwhelming, but if the > original posters had to face two or three of them, I wouldn't blame > them for wanting to do the assembly themselves. > > Our boards are so complex, we don't have a choice but to contract it > out. > > > Of course, you will have to learn how to assemble the kit of parts, and identify them, and > > have a good schematic, and a good bill of materials, and have a good assembly drawing. All of > > that you already have, right? > > My original response in this thread (about assembly and x-ray) was > directed only at the other posters. We use contract manufacturing for > everything, including reworking all but the simple packets. Our > boards come back assembled and ready for testing (although they are > habitually late by 3-5 days). > > This whole discussion is a really a product management discussion > though (engineering could solve any of problems discussed in this > thread). Is there enough PQFP volume to make it worth Xilinx's time > to develop, document, make, stock, market, and sell that part? I'm > guessing not (almost certainly based on customer survey), otherwise > they would have already done it. > > Have fun, > > MarcArticle: 48435
So whats the problem ? First of all you anyway have to generate three files / modules. 1) SRAM 2) Controller 3) BothTogether You use the third file, which puts the two modules SRAM and Controller together, for simulation purposes only and test your design. For your synthesis you only take the controller part. This is straight forward and has nothing to do with the tools at all. Since you always need some sort of testbench, which is only used for simulation purpose. Anyway good luck. Andreas Falkenberg www.DrFalkenberg.com "Engineer" <victor1357@hotmail.com> wrote in message news:b041a362.0210111058.742f72e0@posting.google.com... > Hi all, > I am trying to develop a SRAM controller using Quartus 2.1 from > Altera. The design contains a controller and also a Verilog file with > SRAM model (which I need for simulation and other kinds of > verifications). > The question is: how to separate controller files from SRAM files in a > design, so that Quartus doesn't put SRAM together with controller on a > chip. > Unfortunately, I was not able to achieve this so far. > Any comments appreciated. > ======================== > Victor Ober > TranstechArticle: 48436
"Leon Heller" <leon@heller123.freeserve.co.uk> schrieb im Newsbeitrag news:aok64g$6m6$1@news6.svr.pol.co.uk... > > The are also a couple of older threads on this topic. > > Thanks, Kolja. I remember that thread, now you've mentioned it. I just > copied the Xilinx schematic, I'll bear it in mind if there are problems. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > chips can be socketed, so different ones could be tried, and it would be > easy to modify the PCB. I've never had any problems with the standard Xilinx > Cable III, with my FPGA and CPLD hardware. Perhaps I should open it up, to > check if it matches the schematic. ??? After all those threads about problems with Parallel-III (and copies), why not kick this stupid schematic to hell and do something clean? In my copies, I removed all RC filters, since they look pretty useless, also the diodes are gone. And my copies work fine. To be foolproof, one should add a RC-filter plus two schmitt-triggers in the CLLK/TCK line, to filter any bad glitch/reflection on this line. Havent tested it yet, but should work. -- MfG FalkArticle: 48437
Josh- Comprehensive information on Altera's HDL can be found in the on-line help of Altera's FREE design tools (MAX+PLUS II). In on-line help, there is a dedicated section for AHDL which includes descriptions of the elements, syntax information, and a style guide. If you want access to online help, but don't want to install the actual design tool, you can download the installation executable of the tool, and during installation, you can specify that you ONLY want to install the help file. You can download the software off of Altera's web site at the following location: https://www.altera.com/support/software/download/altera_design/mp2_baseline/dnl-baseline.jsp -Gary SugitaArticle: 48438
On Wed, 16 Oct 2002 12:59:16 +0200, Heiko Kalte <kalte@hni.upb.de> wrote: >Hi community, >I have tried already several times to compare realistic Clock Speeds >(MHz) for the whole Xilinx Families depending on the Technology. I found >out that XC4000XL is 0.35µm; XC4000XV is 0.25µm; Virtex is 0.22µm; >VirtexE is 0.18µm; Virtex2 is 0.15µm and Virtex2Pro is 0.13µm. What I >need are realistic mappings and the resulting Clock Speed for all the >families. I mapped a 32Bit adder to all the families and the result was >a more or less linear increase of the frequency. >XC4000XL=41.137MHz >XC4000XV=66.742MHz >Virtex=101.750MHz >VirtexE=139.567MHz >Virtex2=187.371MHz >Virtex2Pro 3.211MHz > >1. Is that possible??????????? Yes. Also notice that Fmax is proportional to age of part. >2. Is there a Benchmark? Yes. You just did one. >3. Are there similar results in a chart anywhere in the web? Yes. On the part makers web sites. You could start an un-biased one. >4. What are your experiences? Similar to yours. >5. If it is correct, that the speed does not increase that much, what is >the reason for that (in comparison to CPUs, which seems highly >exponential)? The architecture of the cpu changes too. Too lengthy to go into here, but look up "instruction pipeline". (As the speed goes up, the cpu does less per clock, and overlaps the instruction execution.) > >Please help me, it is a part of my PHd!!!!!!! >Heiko > >PS: Have a look on my www.RAPTOR2000.de page >Article: 48439
What Mr. Usselmann said. A good PCI model would be very useful. SH7 On Tue, 15 Oct 2002 10:15:44 -0700, Dave Nelson <pci_model@nelsim.com> wrote: > >I have a PCI model for verilog simulators which includes: > arbiter > master(s) > slave(s) > monitor with GUI > >It is designed to interface with PCI designs to exercise them and display >activity and protocol errors. > >If there is interest, I will release this as open-source software for >free download. > >Requirements: Unix/Linux/Solaris system with gcc compiler > Verilog simulator with PLI interface > >Please email me if you would find this useful. > >Dave Nelson >pci_model@nelsim.comArticle: 48440
The minimum input clock frequency for the Spartan II DLL is 25 MHz - you should check this number for the IIE family. Also, are any of these clocks going off chip? If so, can the external devices work properly at power-on without a clock? Using the DLL, you will not have output clocks present until the FPGA finishes configuration. Barry Brown "Jamie Morken" <jmorken@shaw.ca> wrote in message news:INor9.524711$v53.21823110@news3.calgary.shaw.ca... > Hi, > > I'm working on a board that requires a 120MHz clock, a 24Mhz clock and a > 40MHz clock. > The board has a SpartanIIE device on it. I've never used a PLL (which the > Spartan device has) > so I'm unsure if I should use multiple crystals or if I can use the PLL to > give the needed frequencies. > > One of the IC's requires 24 MHz so would it be possible to use a 24MHz > crystal for this IC and also > feed the output to the FPGA to generate the 40 and 120 MHz clocks? > > cheers, > Jamie Morken > > >Article: 48441
Ray Andraka wrote: > it would be nice to have an option to significantly slow the edges (even the 2mA drive has some > pretty fast edges) to help with SI and EMI on those designs where I/O speed needn't be really fast. > I'm not sure what the implications from a chip design standpoint would be. If this > capability were available, then leaded packages wouldn't be the issue they are now with fast edges, > and you'd likely have a whole lot fewer SI cases to deal with. Ray, how slow do you want them to be ? I just kibitzed in Austin's office, and saw rise and fall times of 6 ns on a "2-mA" output (fast and slow does not make a large difference at this "speed".) HyperLynx is really a fantastic tool :-) Peter Alfke > >Article: 48442
Any suggestions how to make this crappy PS/2 decoder state machine better
appreciated.
DEFINITIONS OF SIGNALS YOU MIGHT NEED TO KNOW
P15, P16 are standard input pins of FPGA
in12Mhz is obviously a 12Mhz clock input pin
Reset is active low input pin
--[ KEYBOARD STATE MACHINE CONTROL SIGNALS ]--
TYPE key_states is (s0, s1, s2, s3, s4, s5, s6, s7);
SIGNAL keystate: key_states;
--[ KEYBOARD INPUT CONTROL SIGNALS ]--
SIGNAL kbparity: STD_LOGIC;
SIGNAL kbinclock: STD_LOGIC;
SIGNAL kbindata: STD_LOGIC;
SIGNAL kbbitcount: INTEGER RANGE 0 to 7;
SIGNAL kbwatchreset: STD_LOGIC;
SIGNAL kbwatchdog: INTEGER RANGE 0 TO 32767;
--[ KEYBOARD IN FIFO SIGNALS ]--
SIGNAL keyhead: INTEGER RANGE 0 to (keybufsize-1);
TYPE KeyMem is ARRAY (0 to keybufsize-1) of STD_LOGIC_VECTOR(7 downto 0);
SIGNAL keydata: keymem;
SIGNAL keyintemp: STD_LOGIC_VECTOR (7 downto 0);
THE CRAPPY CODE
---------------------------------------------------------------------------
-- KEYBOARD HANDLER PROCESS
---------------------------------------------------------------------------
keyboard_handler: PROCESS (reset, in12mhz, keystate, keyhead, p15, p16,
kbinclock, kbindata, keyintemp)
BEGIN
IF (reset = '0') THEN -- reset is active
OR (kbwatchreset = '0') THEN -- watchdog has kicked in
keystate <= s0; -- start on state 0
IF (reset = '0') THEN -- only on reset
keyhead <= 0; -- zero keyboard head
END IF;
kbwatchreset <= '1'; -- watch dog reset high
kbwatchdog <= 0; -- zero watchdog count
kbinclock <= '1'; -- set kbinclock to '1'
kbindata <= '1'; -- set kbindata to '1'
ELSIF rising_edge(in12mhz) THEN -- clock signal edge
kbinclock <= p15; -- latch keyboard clock
kbindata <= p16; -- latch keyboard data
kbwatchreset <= '1'; -- preset watchdog reset
high
IF (kbwatchdog = 32000) THEN -- watch dog has timed out
kbwatchreset <= '1'; -- set watchdog reset signal
ELSE
IF (keystate = s0) THEN -- in state s0 it is stable
kbwatchdog <= 0; -- watchdog never counts
ELSE
kbwatchdog <= kbwatchdog + 1; -- inc watchdog count
END IF;
END IF;
CASE keystate IS
WHEN s0 => -- find clock edge low
keystate <= s0; -- preset stay on this
state
IF (kbinclock = '0') THEN -- falling clock edge
keystate <= s1; -- move to next state
END IF;
WHEN s1 => -- find clock edge high
keystate <= s1; -- preset stay on this
state
kbparity <= '0'; -- clear parity check
kbbitcount <= 0; -- zero bit count
IF (kbinclock = '1') THEN -- clock is now high
keystate <= s0; -- preset error back to s0
IF (kbindata = '0') THEN -- start bit was found
keystate <= s2; -- move to next state
END IF;
END IF;
WHEN s2 => -- find clock edge low
keystate <= s2; -- preset stay on this
state
IF (kbinclock = '0') THEN -- falling clock edge
keystate <= s3; -- move to next state
END IF;
WHEN s3 => -- find clock edge high
keystate <= s3; -- preset stay on this
state
IF (kbinclock = '1') THEN -- clock has gone high
keyintemp(kbbitcount) <= kbindata; -- hold data bit
kbparity <= kbparity XOR kbindata; -- add to parity
IF (kbbitcount = 7) THEN -- 8 bits loaded now
keystate <= s4; -- move to next state
ELSE
kbbitcount <= kbbitcount + 1; -- inc bit in count
keystate <= s2; -- back to wait clock low
END IF;
END IF;
WHEN s4 => -- find clock edge low
keystate <= s4; -- preset stay on this
state
IF (kbinclock = '0') THEN -- falling clock edge
keystate <= s5; -- move to next state
END IF;
WHEN s5 => -- find clock edge high
keystate <= s5; -- preset stay on this
state
IF (kbinclock = '1') THEN -- clock has gone high
kbparity <= kbparity XOR kbindata; -- create parity check
keystate <= s6; -- move to next state
END IF;
WHEN s6 => -- find clock edge low
keystate <= s6; -- preset stay on this
state
IF (kbinclock = '0') THEN -- falling clock edge
keystate <= s7; -- move to next state
END IF;
WHEN s7 => -- find clock edge high
keystate <= s7; -- preset stay on this
state
keydata(keyhead) <= keyintemp; -- store data to key buffer
IF (kbinclock = '1') THEN -- clock has gone high
IF (kbparity = '1') THEN -- parity correct
IF (keyhead=(keybufsize-1)) THEN -- at buffer end
keyhead <= 0; -- roll back to buffer
start
ELSE
keyhead <= keyhead + 1; -- advance buffer position
END IF;
END IF;
keystate <= s0; -- move to start state
END IF;
END CASE;
END IF;
END PROCESS keyboard_handler;
Article: 48443Thank you for your answer. I understand perfectly what you say, and I agree... This is the first time I use an FPGA (it's for a very little design), and I am a bit unexperienced :-) Thank you again.Article: 48444
In article <aomqje$nr2og$2@ID-84877.news.dfncis.de>, Falk Brunner <Falk.Brunner@gmx.de> wrote: >Nowadays, Iwouldnt recommend anythink below 200k. Get a nice Spartan-II(E) >with 200 or even 300k gates. >They are cheap. > >www.nuhorizons.com (200k) >www.burched.com (300k) > >The tools from Xilinx are free. Go for Webpack. Not only that, but consider the following: In a Spartan 2-100, you can do 1.3 Gbps AES encryption. In a $10 part. About 1.7 Gbps in an E. In a Spartan 2-200, you can probably build a 70-80MHz, 2 thread, MIPS or SPARC compatable processor. Probably >100 MHz in an E. In a Virtex 400, you can dump a SYNTHESIZED, GPL'ed SPARC core. Those cheap parts (Spartan II/IIE) are big and powerful, as well as cheap. (I not very wistfully remember doing a sample-based MIDI synthesizer in a 4005 as a class project. It ALMOST fit in a 4003.) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48445
In article <3DAE3821.6DE7648A@andraka.com>, Ray Andraka <ray@andraka.com> wrote: >download and run a design. There is one I am aware of that >duplicates the pushbuttons and displays on a webpage, and even puts a >webcam shot of the board up so you can see the smoke when you fry it >:-) That particular one I think will be open for anyone to use. Send me the URL! I want to experiment with maliciously constructed bitfiles! :) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48446
Jaime Andres Aranguren Cardona wrote: > > Cordial saludo, > ... Congratulations! I wish you well. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 48447
Replied privately. We've seen sub nanosecond rise times on VirtexE with 2mA drive. Sounds like the V2
might be better in this regard.
Peter Alfke wrote:
> Ray Andraka wrote:
>
> > it would be nice to have an option to significantly slow the edges (even the 2mA drive has some
> > pretty fast edges) to help with SI and EMI on those designs where I/O speed needn't be really fast.
> > I'm not sure what the implications from a chip design standpoint would be. If this
> > capability were available, then leaded packages wouldn't be the issue they are now with fast edges,
> > and you'd likely have a whole lot fewer SI cases to deal with.
>
> Ray,
> how slow do you want them to be ?
> I just kibitzed in Austin's office, and saw rise and fall times of 6 ns on a "2-mA" output (fast and
> slow does not make a large difference at this "speed".)
> HyperLynx is really a fantastic tool :-)
>
> 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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48448
--------------4241A076241FD95275756853
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Actually, I think hobbyists may actually have it easier in
some respects now IF they pony up for one of the low cost
eval/development boards such as the insight boards. With
something like that, you get a state of the art device
already placed on the board, in some cases a prototype area
and tools for not much more than you'd pay for the the parts
plus getting a PWB made. You get to do the fun stuff
without having to worry too much about getting a board up
and working.
Austin Lesea wrote:
> Marc,
>
> Well, I now undestand more of the issue. Thanks to all.
>
> Basically a lot of this comes from schools and
> universities, which are actually about 15 years behind the
> times. Even the most presitgious ones (and I won't name
> any names, as they are right here in the Bay Area) are
> unable to assemble or rework something as common as a
> cs144 package CPLD or FPGA. Of course, they are pretty
> lucky, as they can drive down the street and have their
> pick of twenty assembly houses that do short runs only.
>
> I would imagine that they could make a case for buying
> some up to date equipment, but given state budgets, and
> fund raising for private schools, perhaps this just isn't
> possible right now.
>
> There is a lot of equipment on the used market right
> now.....?
>
> It is quite sad, as here is the school that is supposed to
> be teaching the latest and greatest, and they still use
> wirewrap, and dip socketed chips ...... and nothing that
> the student sees after graduation will ever look like
> that.
>
> They miss out learning about signal integrity, 26 layer
> baords, solder thermal profiles, thermal management,
> jitter, etc etc. All really important stuff that takes a
> lot of work to get right.
>
> Now some of the graduate research stuff is up to date, but
> we need BSEE and MSEEs whoa re familiar with this stuff.
>
> Since I am a hobbiest, I also miss being able to work on a
> kit as home that could avail itself of the latest
> technologies. It was really tough to replace a SOIC 24
> lead device with 75 mil centers when I soldered it in 180
> degrees out at home with my solder pull-it remover, 25W
> needle tip iron, and dental pick!
>
> The kit with 14 and 16 pin DIPs is an easy thing to build,
> and one seldom sees surface mount parts of any kind in a
> kit (besides the fact that I can't see them anyway without
> glasses).
>
> There are a few outfits that sell the base board with the
> bga parts mounted, and you have to do all the rest, and I
> like that approach.
>
> Of course, we have the rework station here at work, and I
> could bring it in, and do what is needed here, but it just
> ain't the same thing!
>
> Austin
>
> "Always keep your hobbies from looking and feeling like
> work!"
>
> Marc Randolph wrote:
>
>> Austin Lesea <austin.lesea@xilinx.com> wrote in message
>> news:<3DADEC2C.59DF33D0@xilinx.com>...
>> > Marc (and all),
>> >
>> > Peter wandered by a few moments ago, and asked me why
>> I was so against pq packages?
>> >
>> > I'm not, honestly!
>> >
>> > The Spartan family always has small and inexpensive
>> packages for their parts.
>>
>> Howdy Austin,
>>
>> You're points are all valid, but I think the point of
>> the two guys
>> that originated this typic was that there are a few
>> (perhaps too few?)
>> customers that need some of the features of the V-II ,
>> but for some
>> reason, feel they can't move to a BGA. That means they
>> are stuck
>> waiting for the top-of-the-line features to filter down
>> to the Spartan
>> family in a year or three.
>>
>> > Well, as it so happens, most places close to big
>> technology centers have assembly services
>> > just for prototyping! And it isn't that expensive!
>> In fact, it costs a lot less than having
>> > all of the stuff and people yourself, and not using it
>> (which is what most prototyping
>> > consists of: 5% building, and 95% debugging what was
>> built). They do rework too.
>> >
>> > So ask around. Large assembly services sometimes have
>> a small proto line just for this, and
>> > in areas where there is a lot more business, there are
>> small specialty shops that just do
>> > proto runs.
>> >
>> > And I am talking here about five, two, and sometimes
>> even one board for a reasonable price.
>>
>> In general, I agree with you that the cost of having a
>> board assembled
>> is rather inexpensive (probably less expensive than the
>> original
>> posters realize), especially if they were to include the
>> cost of their
>> own time assembling it rather than paying someone else.
>>
>> But you have to admit there are a few downsides:
>>
>> 1. Turn-around time
>>
>> 2. Correct assembly (even with perfect drawings, from
>> time to time
>> we'll have a few boards with assembly problem).
>> Basicly, nobody is
>> going to be as careful as you in assembling your
>> boards. And if it
>> *MUST* be correct the first time around (due to
>> schedule, or can't
>> afford to do it a second time), who are you going to
>> trust?
>>
>> 3. Location (you point out that contract
>> manufacturing/assembly works
>> best when you're close to technology centers. If I'm
>> not mistaken, at
>> least one of the original posters was in Europe - where
>> I'd expect
>> contract manufacturing/assembly to cost considerably
>> more than in the
>> USA).
>>
>> 4. Cost
>>
>> Any one of these items is probably not overwhelming, but
>> if the
>> original posters had to face two or three of them, I
>> wouldn't blame
>> them for wanting to do the assembly themselves.
>>
>> Our boards are so complex, we don't have a choice but to
>> contract it
>> out.
>>
>> > Of course, you will have to learn how to assemble the
>> kit of parts, and identify them, and
>> > have a good schematic, and a good bill of materials,
>> and have a good assembly drawing. All of
>> > that you already have, right?
>>
>> My original response in this thread (about assembly and
>> x-ray) was
>> directed only at the other posters. We use contract
>> manufacturing for
>> everything, including reworking all but the simple
>> packets. Our
>> boards come back assembled and ready for testing
>> (although they are
>> habitually late by 3-5 days).
>>
>> This whole discussion is a really a product management
>> discussion
>> though (engineering could solve any of problems
>> discussed in this
>> thread). Is there enough PQFP volume to make it worth
>> Xilinx's time
>> to develop, document, make, stock, market, and sell that
>> part? I'm
>> guessing not (almost certainly based on customer
>> survey), otherwise
>> they would have already done it.
>>
>> Have fun,
>>
>> Marc
>
--
--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: 48449rickman <spamgoeshere4@yahoo.com> writes: > Neil Franklin wrote: > > > > > Yes, you are not an FPGA designer. You are on the fringe and you can > > > use whatever you want. But this discussion was about the viability of > > > open source tools and I think you will still find that they will not be > > > well received by the FPGA design community. > > > > For me it is, and has allways been, about making them, and those > > people I know who intend to use them. It you were labouring under > > the impression that I intended to take over the market, then you were > > reading my stuff wrong. > > No, but you have been saying that open source tools will become "better" > than X or A tools. I don't agree that this will ever happen. I think we need to define "better" here. You seem to define it as "supports newest stuff". Open source people define it as "more flexible, less bugs, less usage restrictions", and also an fairly difficult[1] to describe "feels right" that open source stuff has. [1] one ingredient is that it is user-written and therefore simple "fits" the way users work better than anything that is specified by an market research team. > > > have said that they feel they have to provide support to anyone using > > > their chips regardless of the tools they are using. > > > > Simply point out, that it is not out tool - no support - come back > > if problem also happens with our official tool. Open source users > > understand this. > > I don't know what this means. Translation: "we don't support you, unless you use our tools". > > > How could anyone make a bitstream compatible > > > FPGA? Can you explain how they would get around the legal IP issues? > > > > As I said: worst case get an license, in absolute worst case by > > tripping up one of the existing players (if they blankly refuse). IP > > law can be very interesting in that respect. > > > > Also anyone with enough financial interest can actually take an patent > > to court and have it declared irrelevant on an whole range of issues. > > It takes time and cost. But if enough profit are waiting, things like > > that happen. > > Where do open source advocates get the financial backing??? We were not talking of open source (= software) developers here. We are talking about an chip (= hardware) vendors. Such tend to have money, a lot of it. > to cooperate. But if you don't *have* IP, how will you bargan with > them? Any chip company can buy in IP, until they have enough to make A&X listen. Just look at how VIA got round Intels P4 signalling patents by exactly that trick. > > Also you may want to take into account, that Altera managed to > > survive Xilinxes patents, despite starting when they Xilinx had > > maximal protection, and with Altera an latecomer. Any new competitor > > has an easier situation. > > > > And an further scenario: assume bit compatible becomes important. > > Either X or A is the winner in becoming the standard. How long do you > > think will the other of the 2 look at declining sales, until they > > clone? And we already know that a patent battle between them 2 ends in > > stalemate. > > I disagree that a newcomer *now* has an easier time of it. Now you have > not only X to deal with, you have the X&A cartel. Whose remaining patents are becoming more and more detail focussed, as the basic ones are running out. And so easier to circumvent by using an different implementation. The days when simply an LUT or an PIP was an new idea and patentable are over. > They have a vested > interest in keeping others out. Interest yes, but success in doing it? > > The short conclusion: IP law is in no way the "no chance" you seem to > > regard it as. In particular when one has got enough money to run > > through an dedicated battle. > > Well, then show us the money :) A: the entire sub-discussion was about an potential (= not yet the case, and possible never the case) situation B: if the situation arrives, then the money can be shown. Basically that demonstration will point to (part of) the profit possible by cloning. > > > You misunderstand. The did nothing to "help break the license" other > > > than to use the bitstream that came from an Altera tool. > > > > And that is exactly the entire meaning of "help break the license". > > Offering an service that is auxillary to an crime, without any other > > legal use for that service. Look up "contributary infringement" if you > > want an interesting read. I understand the legal concept here very > > well, having read quite a bit on the Napster/Kazaa/etc cases and the > > deCSS/2600/websites cases, and the argumentation against them. > > But you make a point that has nothing to do with the discussion. We are > talking about making chips. In this sub-discussion (of about 5 subdiscussions in this thread) you were claiming that Altera broke Clearlogic on an FPGA patent. I was countering that claim. > > You can get around an patent. Altera survived Xilinxes ones. AMD has > > wrung patents off of Intel, by tripping them over other stuff. Via has > > stopped Intel attacks by tripping them up. Ask an good IP lawyer about > > all the possibilities. IP law is not the clear "you lose" that you > > believe it to be. > > > > In fact the very name IP is an error, they are no property, but rather > > privileges, granted for very specific terms. And many patents do not > > fit those terms, and only survive because being not challenged, because > > fighting them is not profitable. Add an good slice of potential profit > > and the overturning starts. > > Who is going to go up against X and A over these patents? Who has this > money? Whoever convinces an investor or managment that there is money to be made in clones. And no I am not going to try an predict a company name. > > > Yes, but that is not an FPGA is it? The point is that Altera felt a > > > threat and used their IP to shut them down. > > > > The point is that they only just managed. That IP is not the surefire > > "end of competition" you seem to regard it as. > > You say they "just managed" but Clearpoint was not making FPGAs were > they? So how is their case relevant? It is relevant to show you that FPGA patents are not the all-powerfull things you presented them as. Again here: annother sub-discussion. This thread has wandered quite far, even within single posts. > > AFAIK ARMs patent claim was not that strong, they had luck that their > > opponent was weak or possibly simply not interested (better stuff to > > do than fight[1]) and caved in. MIPS had a stronger case against a > > cloner, but their patent is also near/in EOL. > > If the ARM case is not strong, then why does everyone including the > behemoth Intel license rather than "break" the patents? Intel did not just re-implement the ARM instruction set, they actually took over ARM/DEC chip design internals and actual design code (and a few employees AFAIK). That translated into faster to market for them. That is what the license was for, and paid from. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?
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