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
Thanks for the explanation. But I still think the synthesis tools would be more clever. It is very hard for someone with a software background to develop an HDL code suitable for synthesis. It is necessary to have a good knowledge not only of hardware, but also of how synthesizers work. I don't want to offend the synthesizer developers. I know it is a complex problem, but I hope one day we would be able to develop hardware in the same way as software. Thanks again Eduardo. ems@riverside-machines.com.NOSPAM wrote: > > Think hardware. You're asking the synthesiser to produce a clocked > element, which has (a) two clocks (one of which has a higher priority > than the other), (b) one output which is loaded on both clocks, and > (c) another output which is loaded on only the second clock, but only > if there's no edge on the first clock. Your synthesiser doesn't create > new clocked elements - stick with the hardware in your technology > library. > > EvanArticle: 14626
I am looking for a good project board that will take a Xilinx XC4085XL (PGA 559) FPGA. Anyone have any good suggestions? ThanksArticle: 14627
> The only mention of dual-port I could find on the Xilinx site was > in XC4000E and later devices -- I'm using XC4000, the suffix-less, > disowned version. You should be using the libraries FOR that part.....see if the library has the RAM elements. I seem to remember they do have RAM in the non E parts. It was the not really released 4010D that was not supposed to have any RAM.... AustinArticle: 14628
Your Name wrote: > > If you really have invented something useful then patent it! Otherwise, > stop whinning! > > Thank you, Your Name, for your thoughtful and professional advice. JohnArticle: 14629
Brian Drummond <brian@shapes.demon.co.uk> wrote: > On 6 Feb 1999 09:40:53 GMT, Hamish Moffatt <hamish@rising.com.au> wrote: >>The only mention of dual-port I could find on the Xilinx site was >>in XC4000E and later devices -- I'm using XC4000, the suffix-less, >>disowned version. >> > Why not duplicate a single-port memory? > (Which is pretty much what the dual-port RAM cell does internally, so > you won't be losing any efficiency) Trying to save resources. There isn't enough room in the 4010 to duplicate the RAM and the rest of the design which uses it. Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14630
Austin Franklin <austin@dark9room.com> wrote: >> The only mention of dual-port I could find on the Xilinx site was >> in XC4000E and later devices -- I'm using XC4000, the suffix-less, >> disowned version. > You should be using the libraries FOR that part.....see if the library has > the RAM elements. I seem to remember they do have RAM in the non E parts. > It was the not really released 4010D that was not supposed to have any > RAM.... It has RAM -- no problem there, but single port only. thanks, Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14631
I used to use XC4000A and XC4000 (non-E) 5 years ago.
This kind of chips has the only type of built-in
memory: asynchronous single-port memory: RAM16X1, ..., RAM16X8.
I implemented dual-port memory inside XC4000 by means of time-divided
multiplexing.
Address bus and the input data bus of the RAM16X8 element were switched
between two
memory requestors by a Finite State Machine.
Memory output data bits were triggered into two separate registers (each
one - for
a separate memory user).
Special care should be taken, to issue memory write strobe with
sufficient time gap from the moment of switching. So, it is reasonable
to allocate 3 clock cycles for the memory write action, while the memory
read
can be done in 1 cycle.
Regards,
Alex Sherstuk
Sherstuk@amsd.com
AMSD Company
-----Original Message-----
From: Hamish Moffatt [mailto:hamish@rising.com.au]
Posted At: Saturday, February 06, 1999 4:53 AM
Posted To: comp.arch.fpga
Conversation: dual port RAM on XC4000
Subject: dual port RAM on XC4000
Is it possible to do dual-port RAM in an XC4000 (no E)? I want two read
ports, rather than read and write (it's not for a FIFO). I assume not,
since there's nothing at Xilinx's web site about it, but you never know.
thanks,
Hamish
--
Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au
Rising Software Australia Pty. Ltd.
Developers of music education software including Auralia & Musition.
31 Elmhurst Road, Blackburn, Victoria Australia, 3130
Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free:
1-888-667-7839
Internet: http://www.rising.com.au/
Article: 14632"Matthias D. Kistler" <recomp@satie.ee.ethz.ch> writes: > I am looking for the VHDL sources for a DES implementation suitable for > an FPGA. Have a look at http://www.yordas.demon.co.uk/crypto You'll find a pipelined version in VHDL plus a version which uses Xilinx Select-RAM to reduce the size of the S-boxes. Chris -- Chris Eilbeck mailto:chris@yordas.demon.co.ukArticle: 14633
ems@riverside-machines.com.NOSPAM wrote:
>
> Think hardware. You're asking the synthesiser to produce a clocked
> element, which has (a) two clocks (one of which has a higher priority
> than the other), (b) one output which is loaded on both clocks, and
> (c) another output which is loaded on only the second clock, but only
> if there's no edge on the first clock. Your synthesiser doesn't create
> new clocked elements - stick with the hardware in your technology
> library.
>
Using your comments (with some changes), my FIFO, listed below, has:
(a) two clocks one of which (WR_NEG_IN) has a higher priority
than the other (RD_NEG_IN ),
(b) one output (COUNT) which is loaded on both clocks,
(c) two outputs (LAST and MEM_FIFO_HF) that are loaded only on the
first clock ,
(d) one output (FIRST) which is loaded only on the second clock, but
only if there's no edge on the first clock,
In this implementation I could identify only two main differences
from the first one:
1 - The RESET_NEG_IN signal
2 - Both clocks are rising edge.
And the synthesizer produced exactly what I had asked for. What is
the explanation?
Regards
Eduardo
-- Package SVAL_PKG
library IEEE;
use IEEE.std_logic_1164.all;
package SVAL_PKG is
constant WORD_LENGTH_FIFO_HF_C : integer := 5;
constant FIFO_HF_SIZE_C : integer := 7; --255;
constant FIFO_HALF_FULL_HF_C : integer := 4; --128;
constant ZERO_FIFO_HF_C :
std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0) := "00000";
type RAM_FIFO_HF_TYP is array(FIFO_HF_SIZE_C downto 0) of
std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);
constant ZERO_C : std_logic_vector(WORD_LENGTH_C-1
downto 0) := "00000000";
end SVAL_PKG;
--
-- FIFO starts here
--
library ieee;
use ieee.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
use work.SVAL_PKG.all;
entity FIFO_HF is
port ( RESET_NEG_IN : in std_logic; -- '0' -> reset FIFO
RD_NEG_IN : in std_logic; -- '0' -> read FIFO
WR_NEG_IN : in std_logic; -- '0' -> write FIFO
DATA_IN : in std_logic_vector(WORD_LENGTH_FIFO_HF_C-1
downto 0);
DATA_OUT : out std_logic_vector(WORD_LENGTH_FIFO_HF_C-1
downto 0);
FIFO_HALF_OUT : out std_logic; -- '1' when FIFO is > half
full
FIFO_EMPTY_OUT : out std_logic; -- '1' when FIFO is empty
FIFO_FULL_OUT : out std_logic -- '1' when FIFO is full
);
end FIFO_HF;
architecture FIFO_HF_BEH of FIFO_HF is
-- FIFO pointers
signal LAST, FIRST : DATA_SIZE_TYP;
signal COUNT : std_logic_vector (8 downto 0);
signal LAST_IDX, FIRST_IDX : DATA_SIZE_TYP;
-- FIFO memory
signal MEM_FIFO_HF : RAM_FIFO_HF_TYP;
begin
FIFO_PRO: process(RESET_NEG_IN, WR_NEG_IN, RD_NEG_IN )
begin
if RESET_NEG_IN = '0' then
LAST <= ZERO_C;
FIRST <= ZERO_C;
COUNT <= "000000000";
elsif WR_NEG_IN'event and WR_NEG_IN = '0' then -- write to FIFO
if COUNT <= FIFO_HF_SIZE_C then
COUNT <= COUNT + 1;
if LAST = FIFO_HF_SIZE_C then
LAST <= ZERO_C;
else
LAST <= LAST + 1;
end if;
MEM_FIFO_HF(conv_integer(LAST_IDX)) <= DATA_IN;
end if;
elsif RD_NEG_IN'event and RD_NEG_IN = '0' then -- read from FIFO
if COUNT > 0 then
COUNT <= COUNT - 1;
if FIRST = FIFO_HF_SIZE_C then
FIRST <= ZERO_C;
else
FIRST <= FIRST + 1;
end if;
end if;
end if;
end process FIFO_PRO;
LAST_IDX <= LAST;
FIRST_IDX <= FIRST;
DATA_OUT <= MEM_FIFO_HF(conv_integer(FIRST_IDX));
FIFO_HALF_OUT <= '1' when COUNT > FIFO_HALF_FULL_HF_C else
'0';
FIFO_EMPTY_OUT <= '1' when COUNT = 0 else
'0';
FIFO_FULL_OUT <= '1' when COUNT > FIFO_HF_SIZE_C else
'0';
end FIFO_HF_BEH;
Article: 14634I'm looking for a development board that will take a Xilinx XC4085XL (PGA 559) FPGA. Anyone know of any good boards? Thanks in advance, Sanjeev.Article: 14635
Your Name wrote: > > If you really have invented something useful then patent it! Otherwise, > stop whinning! > not a very usefull answer, to get a patent you'll need money and you'll have to reveal everything about how it works, and the patent isn't much more worth than the amount af laywers you can afford to protect it .... --Lasse --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE (to be in 1999) Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 14636
Lasse Langwadt Christensen wrote: > > Your Name wrote: > > > > If you really have invented something useful then patent it! Otherwise, > > stop whinning! > > > > not a very usefull answer, to get a patent you'll need money and > you'll have to reveal everything about how it works, and the > patent isn't much more worth than the amount af laywers you can > afford to protect it .... > > --Lasse > --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- > Lasse Langwadt Christensen, MSEE (to be in 1999) > Aalborg University, Department of communication tech. > Applied Signal Processing and Implementation (ASPI) > http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org Lasse, Since he's rude and illogical, I conclude that he's probably just a lawyer... and lawyers are about the only people who actually benefit from patents. John -- ********************************************************************h John Larkin, President phone 415 753-5814 fax 753-3301 Highland Technology, Inc 320 Judah Street jjlarkin@worldnet.att.net San Francisco, CA 94122 http://www.highlandtechnology.comArticle: 14637
Brian Drummond wrote: > > > >The only mention of dual-port I could find on the Xilinx > site was > >in XC4000E and later devices -- I'm using XC4000, the > suffix-less, > >disowned version. > > > Why not duplicate a single-port memory? > (Which is pretty much what the dual-port RAM cell does > internally, so > you won't be losing any efficiency) > Not quite: The XC4000E and all later flavors (EX, XL, XV, XLA) in dual-port mode apply a common write address (F) to both LUTs inside the CLB, but let you read-address the G-LUT idependently. See the drawing on page 4-16 in the Xilinx data book. It is accurate ( I drew it ). You cannot really achieve the same result with external multiplexing. The dual port scheme writes to both LUTs and lets you read asynchronously and simultaneously by means of the G address. The XC4000E is a more modern, better and faster superset of the XC4000, and it costs less than half of the old XC4000. No reason to decry the lack of features in the old part. Peter Alfke, Xilinx applications Peter AlfkeArticle: 14638
I used to use XC4000A and XC4000 (non-E) 5 years ago. This kind of chips has the only type of built-in memory: asynchronous single-port memory: RAM16X1, ..., RAM16X8. I implemented dual-port memory inside XC4000 by means of time-divided multiplexing. ..... So, it is reasonable to allocate 3 clock cycles for the memory write action, while the memory read can be done in 1 cycle. ---------------------------------------------- Writes can be done in 1 if you gate the WE with the clock. It is best if you control the placement and routing in order to make the timing 'work'. AustinArticle: 14639
If have a design in XC4000 done in Mentor using the obselete libraries, which I want to port to 4000E, can this be done automatically? The process described in XAPP 062 works if you're already on the unified libraries for XC4000 -- does it work from obselete? thanks Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14640
I'm trying to develope software to access memory on the PCI bus through the PLX9050. Does anyone have any examples of how to initialise the chip and read/write to the memory? Ideally I don't want to spend more money on a device driver developement toolkit - there must be some 'C' code for DOS out there somewhere that I can use to get an idea of what needs to be done. Any code or book references welcome. John johnc@ihr.mrc.ac.ukArticle: 14641
While it is probably possible to reverse compile the bit stream, it would be very unlikely that someone would go to that amount of effort. By reverse compiling the bitstream, they only know how each CLB and net connection is routed and would then have to translate that back into readable form. Would probably take more resources than it would to develop their own digital PLL. John Larkin wrote: > Hi, > > I think I've invented a neat circuit for a specialized digital PLL, and > of course I want to keep it proprietary. So if I make a product using a > Xilinx FPGA, the config bitstream can't be hidden from a competitor who > gets his greedy hands on one. I assume that an outright copy is a > copyright violation, so I'm not too worried about that. So here's the > issue: Is it feasible that someone could decompile the stream and > recover the circuit CONCEPT? Are there any tools to help them do this? > Would it be easy, or an enormous task? > -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14642
On Sun, 07 Feb 1999 15:58:04 -0800, Peter Alfke <peter@xilinx.com> wrote: >Brian Drummond wrote: > >> > >> >The only mention of dual-port I could find on the Xilinx >> site was >> >in XC4000E and later devices -- I'm using XC4000, the >> suffix-less, >> >disowned version. >> > >> Why not duplicate a single-port memory? >> (Which is pretty much what the dual-port RAM cell does >> internally, so >> you won't be losing any efficiency) >> > > Not quite: The XC4000E and all later flavors (EX, XL, XV, >XLA) in dual-port mode apply a common write address (F) to >both LUTs inside the CLB, but let you read-address the G-LUT >idependently. See the drawing on page 4-16 in the Xilinx >data book. It is accurate ( I drew it ). Sure. There are differences in detailed operation. We're not disagreeing here (between "pretty much" and "not quite" :) I just wasn't explicit enough, relying on context supplied by the original post and the databook. >You cannot really achieve the same result with external >multiplexing. The dual port scheme writes to both LUTs and >lets you read asynchronously and simultaneously by means of >the G address. But in the context of the original question - two independent read ports (no simultaneous write) were all that was called for. For this restricted functionality, others also have pointed out you can mimic dual-port. Now you _would_ need (minimal) additional resources to share the address buses on write, but this is minimal compared to the memory itself. The major disadvantage of duplicating single-port memory, namely a halving in the capacity available, is equally true of the dual-port RAM since you get 16*1 bits per CLB instead of 16*2 or 32*1 per CLB... (unless there's been a major update since my 1996 data book?) It can be done - provided you can accept the hit in resources. And if you can't, the newer series won't help you. This was the point I was making, and Hamish subsequently expressed that resources (not the exact functionality) was his main concern. >The XC4000E is a more modern, better and faster superset of >the XC4000, and it costs less than half of the old XC4000. >No reason to decry the lack of features in the old part. Unless you had a large supply of them, and no money! Or maybe your tools only support the old ones, and your support contract has expired. Or maybe that's whats soldered to the boards you inherited. Unfortunately, not everyone works for a billion dollar company (yet...) The quality of support for established users, stuck with older (even obsolete) product lines, says quite a lot about a company. Especially to those folks trying to justify a large (and, they hope, long-term) investment today. - BrianArticle: 14643
On 7 Feb 1999 10:19:26 GMT, Hamish Moffatt <hamish@rising.com.au> wrote: >Brian Drummond <brian@shapes.demon.co.uk> wrote: >> On 6 Feb 1999 09:40:53 GMT, Hamish Moffatt <hamish@rising.com.au> wrote: >>>The only mention of dual-port I could find on the Xilinx site was >>>in XC4000E and later devices -- I'm using XC4000, the suffix-less, >>>disowned version. >>> >> Why not duplicate a single-port memory? >> (Which is pretty much what the dual-port RAM cell does internally, so >> you won't be losing any efficiency) > >Trying to save resources. There isn't enough room in the 4010 to duplicate >the RAM and the rest of the design which uses it. > In that case you may have the same problem with the dual-port cell, since its capacity is half the single-port cell (16*1 not 32*1 per CLB). See my reply to Peter Alfke. - BrianArticle: 14644
Why don't you send us your resume. I am the apps manager for Atmel FPGA group, I can pass it onto micro apps as well. I am always interested in people who really want to do apps. Send to fpga@atmel.com Wendy *** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***Article: 14645
hmmm, what i probably should have mentioned: i generate approx. 100 designs/hour. so interactive methods are not at all doable. it has to be a robust automated method! Ray Andraka wrote: > > Try doing a little floorplanning. Also, keep in mind how the design will > get implemented as you do the design. Try to avoid routing congestion. > > Now, if you are dealing with partial reconfiguration, you shouldn't be using > synthesis. With partial configuration it is important that the pieces of > the design that are to stay in-place remain untouched...this means > implementation, placement and routing. This calls for a structural code, > and is extremely tedious to do. > > Endric Schubert wrote: > > > i work in the field of reconfigurable computing and i will never get > > used to the following message from my FPGA back-end tools: > > > > no placement/routing found ... > > > > or, if i was lucky enough, the tool found a fit after several hours. > > but, c'mon, synthesizing the damn thing with a state-of-the-art tool > > took a couple minutes! > > > > so i think its time to post something about this matter and see what the > > net thinks about it: > > > > if you've done some serious FPGA designs, you probably know the facts of > > routability: > > > > 1. re-running P&R doesn't help! > > some algorithms are non-deterministic, so why not try one more time? > > since for some FPGAs its worse than winning in a lottery! > > > > 2. decreasing device utilization doesn't help! > > sometimes - especially when you have pin constraints - not even > > decreasing it to a ridiculously low 50% helps! > > > > 3. there are no better P&R tools! > > unfortunately, there is no 3rd party supply for P&R tools (unlike for > > synthesis), so you're stuck with the vendors tools. and their tools seem > > not to be too concerned about routability. hey, they want to sell > > silicon, and when they get you down to 50% device utilization, they'll > > suceed! :-> > > > > 4. you cannot re-synthesize for improved routability! > > knowing, that no synthesis tool supports "synthesis for routability" (at > > least i don't know any), all you can do is switch off all the > > optimizations (you're down at 50% device utilization so what do you care > > about one more LUT?). or if you've optimized for area (delay), you now > > optimize for delay (area). > > > > as an EDA developer i know that there are algorithms avail, that > > estimate routability in synthesis, that can improve routability (e.g. > > thru replication of logic, or running a different decomposition). also, > > there are more decent P&R algorithms avail, than the ones you get with > > your vendors P&R tool. > > > > all i want is a *robust* FPGA design flow, but why can't i buy any? > > > > my explanation is: there is no demand for it! > > > > Endric > > > > (speaking for himself, not for his employer) > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randrakaArticle: 14646
Have you looked at using something like javabits? If you have an idea of what the logic you are generating is, you should be able to apply at least a little smarts to the implementation and layout. Javabits will let you generate implementation and layout automatically. Endric Schubert wrote: > hmmm, what i probably should have mentioned: i generate approx. 100 > designs/hour. so interactive methods are not at all doable. it has to be > a robust automated method! > > Ray Andraka wrote: > > > > Try doing a little floorplanning. Also, keep in mind how the design will > > get implemented as you do the design. Try to avoid routing congestion. > > > > Now, if you are dealing with partial reconfiguration, you shouldn't be using > > synthesis. With partial configuration it is important that the pieces of > > the design that are to stay in-place remain untouched...this means > > implementation, placement and routing. This calls for a structural code, > > and is extremely tedious to do. > > > > Endric Schubert wrote: > > > > > i work in the field of reconfigurable computing and i will never get > > > used to the following message from my FPGA back-end tools: > > > > > > no placement/routing found ... > > > > > > or, if i was lucky enough, the tool found a fit after several hours. > > > but, c'mon, synthesizing the damn thing with a state-of-the-art tool > > > took a couple minutes! > > > > > > so i think its time to post something about this matter and see what the > > > net thinks about it: > > > > > > if you've done some serious FPGA designs, you probably know the facts of > > > routability: > > > > > > 1. re-running P&R doesn't help! > > > some algorithms are non-deterministic, so why not try one more time? > > > since for some FPGAs its worse than winning in a lottery! > > > > > > 2. decreasing device utilization doesn't help! > > > sometimes - especially when you have pin constraints - not even > > > decreasing it to a ridiculously low 50% helps! > > > > > > 3. there are no better P&R tools! > > > unfortunately, there is no 3rd party supply for P&R tools (unlike for > > > synthesis), so you're stuck with the vendors tools. and their tools seem > > > not to be too concerned about routability. hey, they want to sell > > > silicon, and when they get you down to 50% device utilization, they'll > > > suceed! :-> > > > > > > 4. you cannot re-synthesize for improved routability! > > > knowing, that no synthesis tool supports "synthesis for routability" (at > > > least i don't know any), all you can do is switch off all the > > > optimizations (you're down at 50% device utilization so what do you care > > > about one more LUT?). or if you've optimized for area (delay), you now > > > optimize for delay (area). > > > > > > as an EDA developer i know that there are algorithms avail, that > > > estimate routability in synthesis, that can improve routability (e.g. > > > thru replication of logic, or running a different decomposition). also, > > > there are more decent P&R algorithms avail, than the ones you get with > > > your vendors P&R tool. > > > > > > all i want is a *robust* FPGA design flow, but why can't i buy any? > > > > > > my explanation is: there is no demand for it! > > > > > > Endric > > > > > > (speaking for himself, not for his employer) > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14647
Hello Mr. Stan, Is the job in Boston still available? I am very interested in contracts of this type. I specialize in Xilinx design, especially high speed data flow (50 MHz - 100 MHz). I am extremely well versed in Xilinx and have a large amount of experience with logic placement and routing optimization. I feel this is a unique skill/craft that most FPGA designers lack and would be quite useful for this type of design. Design experience includes telemetry processing equipment for NASA that links all of their ground stations together, various R&D projects, and safety systems.. I have 8+ years experience with all levels of board design (digital and analog) from concept to finial product. Thank you for your time and consideration and look forward to you reply. Regards, Steve Swearingen sasweari@orbitworld.netArticle: 14648
I recently posted an email regarding a contact job to this address by mistake. Please accept my apologies. Steve SwearingenArticle: 14649
Where can I find the archives for this newsgroup? -- To reply please remove the nospam from the reply address. regards, Ted
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