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 think you have hit the nail on the head with this comment. If you have a lot of resources free then HDL is the way to go as you get fast turnaround. If you want optimum density/speed Schematics are the way to go. I would suspect that Xilinx and the other FPGA companies are basing thier decisions on the "must get it out quick" attitude, as who could possibly hand craft a 2 Million Gate FPGA (Virtex in the future) ? IMO, this should not be their decision but should be their customers'. This is the only way I see a good balance of designs. On one hand it's the quick and dirty approach (fast turnaround and market presence) and on the other it's the long and windy approach (hand craft and optimize until you use 95-100% of the device). HDL's can be good at algorithmic stuff when you want to check whether a principle works or you have a load of resources available on the FPGA (you can get fair speeds out of this) but if you really need to hand-craft to get high-speed and efficient density, then Schematics is probably a favourable solution. Another reason for FPGA's Vendors using HDL is that traditionally HDLs are used for ASIC design and as far as the FPGA vendors are concerned, they are in the ASIC market with large density FPGAs (which is probably quite true now). With this in mind, getting a product to market in a timely fashion is a bigger requirement than optimizing a design by hand-crafting. ------------------- Gareth BaronArticle: 12601
In article <705c56$ba3@masters0.InterNex.Net>, Gareth Baron <Gareth.Baron@eng.efi.com> writes >For fairly low tech. apps Programmable hardware is definitely a viable >solution. The problem is that if the quantities are large then ASIC is >difintely worth it as FPGAs (especially large densities) are quite >expensive. > >When prices come down on the FPGA front (>1M gates) this is definitely one >of my "want's". Again this may be, as you say, a pipedream as the ASIC >densities will go up as well. As things get bigger the FPGA will begin to look relatively better because the ASIC has to go through a design cycle whereas the FPGA will just need programming(?!) once the base chip is available. The other advantage the FPGA has is that it can be reprogrammed in the field for several different functions. -- Richard CantArticle: 12602
..... you need to massage the (VHDL) code so > that it generates the logic you already know would be an efficient > implementation. Don't you mean 'guess at what implementation would generate...'? Austin P.S. Ray, you responded so well....I was tempted, but I just wouldn't have said it like you did...Article: 12603
Dear William Yes. it actually uses address bits [19:11]. They are enough to decode such values. I found Cypress Synthsizer Warp can do it. (See the book "VHDL for Programmable Logic" by Kevin Skahill of Cypress Semiconductor, pp.181) It also can be done in very old PAL/GAL devices' compiler like CUPL. I used to do this in designing the ISA AT bus cards to decode the bus address I/O read, write and memory read/write. ----------------------------------------------------------------------- In article <362B7475.2D475875@hti.com>, William <wlhunterjr@hti.com> wrote: > Could it be that ADDR is defined to be only 9 bits and you are comparing it against > 20 bits. > > leslie.yip@asmpt.com wrote: > > > Hello Everybody > > > > I think that this is technology-declining that ViewLogic can't know how to > > synthesize the code. In the past time, (ten or more years ago) the CUPL can > > synthesize it into P22V10 or 16V8 PAL/GAL devices. I can't understand how > > ViewLogic can't know that. > > > > The synthesized result should be similar to that as follows: > > > > -- Mem_dec.vhd > > > > library ieee; > > use ieee.std_logic_1164.all; > > use ieee.std_logic_unsigned.all; > > > > Entity MEM_DEC is > > port( ADDR: in std_logic_vector(19 downto 11); > > NMEMR,NMEMW: in std_logic; > > -- NRST: in std_logic; > > RAMCE: out std_logic; > > DPRA,DPRB: out std_logic); > > end MEM_DEC; > > > > architecture MEM_DEC_ARCH of MEM_DEC is > > -- signal dint,ddint: std_logic; > > -- signal rint,fint: std_logic; > > > > begin > > > > process(ADDR, NMEMR, NMEMW) > > begin > > DPRA <= '0'; > > DPRB <= '0'; > > RAMCE <= '0'; > > if NMEMR='0' or NMEMW='0' then > > if ADDR = "110101000" then > > DPRA <= '1'; > > elsif ADDR = "110101001" then > > RAMCE <= '1'; > > elsif ADDR = "110110110" then > > DPRB <= '1'; > > end if; > > end if; > > end process; > > > > end MEM_DEC_ARCH; > > > > ---------------------------------------------------------------- > > In article <70abgn$d38$1@news.inter.net.il>, > > "Ido Kleinman" <kleinn@REMOVETHIS.mail.biu.ac.il> wrote: > > > Your VHDL code is alright and would compile nicely under Active-VHDL (from > > > Aldec). > > > I am pretty sure that Aurora doesn't know to interpret constant bit_vectors > > > in the format x"D400". I've already encountered some compiliers/synthesizers > > > which can only accept binary based constant vectors such as > > > "1101010000000000".. Try removing that x prefix and changing the radix of > > > the comparison. > > > > > > -- > > > > > > Yours, > > > > > > - Ido Kleinman. > > > kleinn@REMOVETHIS.mail.biu.ac.il > > > > > > ** Please delete the "REMOVETHIS." > > > ** substring to EMail me. > > > > > > leslie.yip@asmpt.com wrote in message <706oci$9uo$1@nnrp1.dejanews.com>... > > > >Hello Everybody, > > > > > > > >I would like to know what is worng with the ViewLogic's Synthesizer > > > "Aurora" > > > >to interpret the following code. > > > > > > > >The error message is as follows: > > > > > > > >The following is a list of the navigable error/warning messages in the > > > >preceding run. Double clicking on a message will bring up the Viewer with > > > the > > > >cursor positioned at the offending line of code. VHDL: Error: > > > >d:\vhdl_mfb3\mem_dec\mem_dec.vhd, line 28: impossible to determine the > > > type > > > >of this parameter VHDL: Error: d:\vhdl_mfb3\mem_dec\mem_dec.vhd, line 30: > > > > impossible to determine the type of this parameter VHDL: Error: > > > >d:\vhdl_mfb3\mem_dec\mem_dec.vhd, line 32: impossible to determine the > > > >type of this parameter End navigable error/warning messages. > > > > > > > > > > > > > > The code: > > -------- > > > > -- Leslie Yip, ASM; Jun, 8, 1998 > > -- Mem_dec.vhd > > > > library ieee; > > use ieee.std_logic_1164.all; > > use ieee.std_logic_unsigned.all; > > > > Entity MEM_DEC is > > port( ADDR: in std_logic_vector(19 downto 11); > > NMEMR,NMEMW: in std_logic; > > -- NRST: in std_logic; > > RAMCE: out std_logic; > > DPRA,DPRB: out std_logic); > > end MEM_DEC; > > > > architecture MEM_DEC_ARCH of MEM_DEC is > > -- signal dint,ddint: std_logic; > > -- signal rint,fint: std_logic; > > > > begin > > > > process(ADDR, NMEMR, NMEMW) > > begin > > DPRA <= '0'; > > DPRB <= '0'; > > RAMCE <= '0'; > > if NMEMR='0' or NMEMW='0' then > > if ADDR >= x"D4000" and ADDR <= x"D47FF" then > > DPRA <= '1'; > > elsif ADDR >= x"D4800" and ADDR <= x"D4FFF" then > > RAMCE <= '1'; > > elsif ADDR >= x"DB000" and ADDR <= x"DB7FF" then > > DPRB <= '1'; > > end if; > > end if; > > end process; > > > > end MEM_DEC_ARCH; > > > > -----------== Posted via Deja News, The Discussion Network ==---------- > > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own > > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 12604
Geir Harris Hedemark wrote:
> rk <stellare@NOSPAMerols.com> writes:
> > many cases HDL's are a better design option. for pushing speed,
> > density, or power, it is simply, with today's technology, easier to
> > draw a schematic.
>
> I don't know about density or speed, but I am absolutely certain that
> doing things like clock gating with schematics is enormously (sp?)
> inefficient. Power Compiler is smart enough to do this for me.
er, clock gating in an fpga should be done very carefully and, no offense
to your power compiler, but a humanoid should be involved in that
decision.
----------------------------------------------------------------------
> > while constraints help guide a tool, they can not replace circuit
> > architectural decisions, currently still a domain where the humans
> > have the edge over the synthesizer.
>
> If you have not put your architectural decisions into your VHDL code,
> it probably won't be synthesizable. If it is, then you have not
> written it right.
>
> If you mean what kinds of adders to use to minimize power, Synopsys
> has something called Designware. You can put your low-power carry save
> adders in there. Power Compiler will then help choose the
> implementation with the lowest power usage that still meets timing.
yes, i do mean things like adder architecture. i'm sure i can spend a lot
of time and a lot of $ and get all of the options into the DW libraries.
do the fpga-vendor supplied libraries for synopsys dw have all of the
options in it and can out do a human? does the engineer have to put it
in? let's assume yes, the human has to add designware libraries. i think
that you will find for these critical circuits the time spent messing with
the tool, the cost of the tools (er, synopsys and it's options are exactly
freeware) is rather expensive and, as the original poster pointed out, the
goals could be met easier and quicker with a schematic. for example, i've
done some very high performance multipliers well tuned to the architecture
i was implementing them - haven't seen an architecture in the design ware
libraries to meet my requirements. once figured out, easy to draw with a
schematic and easy to read.
please add up the cost of the software you mentioned here or implied:
design compiler
fpga compiler
power compiler
designware stuff
training classes (just went through some at day job, not cheap, didn't
give out donuts, either).
not cheap. and if i can do the critical sections quicker w/ a cheap
schematic too and the non-critical sections in a cheap vhdl compiler
that's a win for me. buying all of that expensive software would, well,
push me right out of my house.
of course, there are the nice HDL tools which insist that they are smarter
than the human and disregard the instructions they are given until you:
a) figure out what they did
b) figure out how to over-ride the tool's decision.
----------------------------------------------------------------------
> Better yet: Just say which adders you prefer to Design Compiler. Works
> as a charm.
easier to just write it down in a schematic. works like a charm. every
time.
rk
Article: 12605
Yves Tchapda wrote:
> Hi,
> We are developing a high bandwidth switch architecture and we need to
> test each switch interface at maximum speed of 100MB/s, which with an
> 8-bit interface requires a clock of 100MHz. Is there any FPGA out
> there that would be able to sustain pumping data at this rate? I
> thought of using a slower clock and a 32-bit interface from the FPGA
> and then probably use a CPLD to multiplex the data to the switch 8-bit
> interface. But there are problems associated with this. Any
> suggestions?
>
> Dr Yves Tchapda
> e-mail yves@px.uk.com
The Altera FLEX10KB100 (-2,-1 speed grade) clocks comfortably in at 100
MHz, both internally and between similar devices. Note that this is a 2.5=
V
part (I/O is 2.5, 3.3 or 5V).
--
Hans Christian L=F8nstad ^ ^ Data Respons AS
| / \__.---- Sandviksveien 26
Real Time | / 1322 H=F8vik
Professionals --------------> Norway
mailto:Hans.Christian.Lonstad@datarespons.no
http://www.datarespons.no
Article: 12606Ken Coffman wrote: > The conversion from binary to Gray code is not too bad. The best solution > might be to implement a fast binary counter, then convert the binary to > Gray. > > I can post the algorithm to convert binary to Gray if necessary. > > If the output code is not important, and high speed with low EMI is the > goal, perhaps a LFSR counter is the answer. > > What's the design goal? What is the meaning of LFSR?Article: 12607
vic@alpha.podol.khmelnitskiy.ua wrote: > http://www.fernuni-hagen.de/IT/FPGA/news Archiv starting February 1997 MarkusArticle: 12608
Watching this seemingly eternal schematics vs. HDL argument I find myself, typically, agreeing with both sides. Schematics for their intuitive nature, at least for datapath stuff - state machines are more problematic. HDL for speed of writing & modifying random logic. What wins it for me is that the text nature of HDLs make them amenable to source code revision control, difficult or impossible with schematics [Correct me if I'm wrong here]. Also , using lots of instantiation, you can treat HDLs as text based schematics but the reverse process is awkward.Article: 12609
For Sell by individual: Aldec's ActiveCAD 2.2 with Altera FPGAs, PLD, TTL, etc. libraries/models, VHDL model compiler, Schematic Entry, System (board level) simulation, Graphical State Machine Entry. Keylock, and license transfer. $1800.00 or best reasonable offer. MINC's Synario Board Designer Version 4.11 (latest) with aprx one years maintenance (Renewed maintenance 9-8-98), keylock and license transfer. $1150.00 or best reasonable offer. Borland's Delphi Version 2.0 Professional and C++ Version 4.5 Professional, with loads of documentation. $100.00 or best reasonable offer. CUPL Multi-vender, multi-chip FPGA Designer Software (complete FPGA, PAL, and PLD/EPLD design) $350.00 or best reasonable offer. TANGO Schematic entry for DOS. $50.00. Buyer pays shipping. contact: rbrooks4@gte.net -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 12610
So, for design capture, simulation, and place/route do you swear by that button-infested GUI with it's 'at-a-glance' 'ease-of-use' 'fully-integrated-look-&-feel'..., or, do you go for the 'rocket-science' 'light-the-blue-touch-paper-and-retire' script approach, and amaze your friends? My preferences are probably obvious from the title :-) I run everything from XEmacs (with electric-vhdl etc) and use the 'M-x compile' feature to run scripts and quickly fix my bug-ridden designs. Everything is scripted, and the scripts are source-code controlled and available for anyone to re-create/modify my design flow. I get hot under the collar when I hear of CAE vendors 'adding value' (increasing cost to me) by tarting up the GUI and ignoring the wishes of us script-writers. My message to the vendors would be: less GUIs, cheaper tools with powerful scripting and plenty of script-based app notes etc. Lets take a vote on it! Nick. ============================================================================ Nick Gent Telecommunications Network Test Division Hewlett-Packard Telephone: +44 131 331 7644 South Queensferry EH30 9TG Fax: +44 131 331 7488 Scotland mailto:nick_gent@hp.com ============================================================================Article: 12611
Rick wrote: > > Graeme Durant wrote: > > > Under Known Issues it says that the revision control mechanism only > > handles implementation data, and that you have to manually handle > > your source code/netlists if you want to keep them. > > I think that the general theory among FPGA EDA vendors is that source code > revision control is for wussy s/w engineers not us hairy chested h/w types. If > this wasn't so why haven't they included one of the free or shareware > implementations of Unix's RCS - which has been around for years. And while > they're at it why don't they throw in Emacs 19 + verilog/vhdl-mode + make and > hey presto the GUI's disappeared altogether. > > Does anybody actually like the idea of having 3 GUIs to implement a Xilinx > design via Foundation Express - the F.E. one, Project manager, Design manager ? I love it ;-( For my company I have developed a flow for each project NOT using the GUI! Why you ask, to give me flexibility to add/remove/modify any tool in the flow. The GUIs are a pain, but look nice at a DAC demo or for someone who only does designs once in a "blue moon." But herein lies the problem the once in the "blue moon" designer has to learn a new tools set every time because there have been so many changes. I am thankful that the FPGA vendors have still left us the command line back door because without that we would all have "Repetitive Stress Syndrome" from all the mousing around the GUI requires. Tom Tessier -- +------------------------ ---------------------- ----------------------+ : t2design : : 249 Lois Drive : : Louisville, CO 80027 : +------------------------ ---------------------- ----------------------+ : tomt@hdl-design.com * (303)665-6402 * Fax: (303)665-6431 : +------------------------ ---------------------- ----------------------+Article: 12612
Has anybody try to use different output file format (x.edf or x.xnf) with Galileo? When I use them with the xilinx M1.4, it seems to me that the result is 10% slower for the x.xnf file. The problem is that I use macro-function from Coregen (from xilinx) in a xnf format. So all the files must be in xnf format. Thank you. Michel.Article: 12613
Gareth Baron wrote: > I would suspect that Xilinx and the other FPGA companies are basing thier > decisions on the "must get it out quick" attitude, as who could possibly > hand craft a 2 Million Gate FPGA (Virtex in the future) ? > > IMO, this should not be their decision but should be their customers'. That would be great if Xilinx had unlimited resources. But in the real world they have limited dollars to spend on developing tools. One would assume that they have decided that supporting the use of schematic tools with the Virtex chips has reached the point of diminishing returns in terms of how many customers would use them. Xilinx can't always give everyone everything they want. This may just be getting too expensive for them. So I am sure that if people call Xilinx and tell them that these tools are still "required", they will spend the time and money to support them. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12614
Rickman wrote: > VHDL synthesizer I am using that is done with an attribute statement. > > -- 1 2 4 8 > type StateType is (IDLE, MEMREQ, MEMXFER, CNTLREQ, -- 1 > CNTLXFER, STATREQ, STATXFER, FREQREQ, -- 10 > FREQHOLD, FREQXFER, TESTREQ, TESTRD, -- 100 > TESTWR, PREIDLE); -- 1000 > > attribute enum_encoding : string; > attribute enum_encoding of StateType : type is "one hot"; > > Once the synthesizer sees this it should not only synthesize your FFs as > one-hot, but should understand to only look at one FF to decode each > state. For example this is the code I use to assign a name to the IDLE > state output signal. > > signal CurState : StateType; > signal NxtState : StateType; > signal IdleSt : std_logic; > > IdleSt <= '1' when CurState = IDLE else '0'; > > I don't know how portable the above code is. You might try a simple test > case on your tools. I do know that this is recommended in many VHDL > books. > > -- > This is fine if the compiler/synthesiser can handle it but is there any way if doing it within the IEEE language definition(s) [as there is in Verilog with the casex construct] without using 1 `if' statement per state ?Article: 12615
Le mer Michel wrote in message <362C47E3.69E9FBD8@ago.fr>... >Ken Coffman wrote: > >> The conversion from binary to Gray code is not too bad. The best solution >> might be to implement a fast binary counter, then convert the binary to >> Gray. >> >> I can post the algorithm to convert binary to Gray if necessary. >> >> If the output code is not important, and high speed with low EMI is the >> goal, perhaps a LFSR counter is the answer. >> >> What's the design goal? > >What is the meaning of LFSR? > Linear Feedback Shift Register. TI have an app-note called "What's an LFSR?". http://www.ti.com/sc/docs/psheets/abstract/apps/scta036a.htmArticle: 12616
hi rick, well, a few days ago, i received the hdl for a chip that i am supposed to review and troubleshoot [day job]. now, the original design was done in schematics by one company who passed it to a sub who passed it to a sub who passed it to a sub. well, the final sub entered the schematics into vhdl so i received over a dozen ascii files all consisting of mostly structural vhdl. i would say that this awkward since to understand the design at all, i must make a drawing [as an old human i'm not very good at reading netlists]. plus one must also understand what the synthesizer did to the code. in my opinion, this was the worst possible choice. the design was not pushing performance limits with the highest clock rate at 500 kHz nor was it obviously density limited since i doubt the synthesizer would do nearly as well as a human there. i did run some of their "code" through a synthesizer and it just didn't get it optimized to the architecture at hand. in this case either rtl vhdl or schematics would have been superior. my $0.02, rk ----------------------------- Rick Filipkiewicz wrote: > Watching this seemingly eternal schematics vs. HDL argument I find myself, > typically, agreeing with both sides. Schematics for their intuitive nature, > at least for datapath stuff - state machines are more problematic. HDL for > speed of writing & modifying random logic. What wins it for me is that the > text nature of HDLs make them amenable to source code revision control, > difficult or impossible with schematics [Correct me if I'm wrong here]. Also > , using lots of instantiation, you can treat HDLs as text based schematics > but the reverse process is awkward.Article: 12617
Rick Filipkiewicz wrote:
>
> Rickman wrote:
>
> > VHDL synthesizer I am using that is done with an attribute statement.
> >
> > -- 1 2 4 8
> > type StateType is (IDLE, MEMREQ, MEMXFER, CNTLREQ, -- 1
> > CNTLXFER, STATREQ, STATXFER, FREQREQ, -- 10
> > FREQHOLD, FREQXFER, TESTREQ, TESTRD, -- 100
> > TESTWR, PREIDLE); -- 1000
> >
> > attribute enum_encoding : string;
> > attribute enum_encoding of StateType : type is "one hot";
> >
> > Once the synthesizer sees this it should not only synthesize your FFs as
> > one-hot, but should understand to only look at one FF to decode each
> > state. For example this is the code I use to assign a name to the IDLE
> > state output signal.
> >
> > signal CurState : StateType;
> > signal NxtState : StateType;
> > signal IdleSt : std_logic;
> >
> > IdleSt <= '1' when CurState = IDLE else '0';
> >
> > I don't know how portable the above code is. You might try a simple test
> > case on your tools. I do know that this is recommended in many VHDL
> > books.
> >
> > --
> >
>
> This is fine if the compiler/synthesiser can handle it but is there any way
> if doing it within the IEEE language definition(s) [as there is in Verilog
> with the casex construct] without using 1 `if' statement per state ?
Sorry, I left out the case statement since I thought that was "obvious"
;^(
You would not want to use nested IF statements since they give the
resultant logic a priority oriented structure. A case statement will
have equal priority to each of the cases.
Here is most of my state machine to handle address decoding and timing
of the various internal interfaces.
-- Bus Interface Machine Logic
StateLogic: process (AdsN, LADIn, LWR, StartXfer, LastWordN, BlastN,
CurState) begin
case CurState is
when IDLE =>
if (AdsN = '1') then
NxtState <= IDLE;
else -- Address valid, check it
if (LADIn (26) = '0') then
NxtState <= MEMREQ; -- Memory read
elsif (LADIn (7) = '0') then
NxtState <= IDLE;
else -- Access to Registers
case LADIn (3 downto 2) is
when "00" =>
NxtState <= CNTLREQ;
when "01" =>
NxtState <= STATREQ;
when "10" =>
NxtState <= FREQREQ;
when "11" =>
NxtState <= TESTREQ;
end case;
end if; -- elsif LADIn 7
end if; -- if AdsN
when MEMREQ =>
if (StartXfer = '1') then
NxtState <= MEMXFER;
else
NxtState <= MEMREQ;
end if;
when MEMXFER =>
if (LastWordN = '0' or BlastN = '0') then
NxtState <= PREIDLE;
else
NxtState <= MEMXFER;
end if;
...sniped many cases...
when TESTREQ =>
if (LWR = '0') then
NxtState <= TESTRD;
else
NxtState <= TESTWR;
end if;
when PREIDLE =>
NxtState <= IDLE;
end case;
end process;
I hope this helps.
--
Rick Collins
redsp@XYusa.net
remove the XY to email me.
Article: 12618This is a multi-part message in MIME format. --------------48F2F213E8EFF132AE74780E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Filipkiewicz wrote: > Watching this seemingly eternal schematics vs. HDL argument I find myself, > typically, agreeing with both sides. Schematics for their intuitive nature, > at least for datapath stuff - state machines are more problematic. Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic, at least one-hots. If you want to get fancy, the FF carrying the state can be wrapped in a symbol with one or two (or more) inputs: enter (for a transitional state active for only one cycle), enter and exit, enter and hold, choose your own combo's. The transition logic is usually a simple sum of products applied to either of the two state control inputs. Almost as easy to read as a state diagram. Also, you know what it will compile into, as opposed to one SM -> HDL -> netlist tool I've looked at, which ended up producing circuits 50% to 100% larger than the schematic. And a 100% larger circuit is likely to run half-fast. Portability --> HDL Performance --> Schematic --------------48F2F213E8EFF132AE74780E Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John L. Smith Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: John L. Smith n: Smith;John L. org: Visicom Imaging Products adr: 1 Burlington Woods;;;Burlington;MA;01803;USA email;internet: jsmith@visicom.com title: Principal Engineer tel;work: 781-221-6700 tel;fax: 781-221-6777 note: http://www.visicom.com/products/Vigra/index.html x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------48F2F213E8EFF132AE74780E--Article: 12619
This is a multi-part message in MIME format. --------------39153669E1DCF15E842D4D8B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does anybody have footprints for Altera's BGA packages? I'm using Protel 98 for PCB layout, and they don't provide any support for any BGA packages. Actually, all I really need is a recommended land pad size for the standard BGA ball, which is 30mils diameter with 50mils between centers. Protel has a component wizard that can do the grid layout for me. Sorry if this is a little off-subject, but I can't seem to get the info anywhere else. --------------39153669E1DCF15E842D4D8B Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bryn Wolfe at IEEE Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Bryn Wolfe at IEEE n: Wolfe at IEEE;Bryn org: Metrica TRACLabs adr: 1012 Hercules Drive;;;Houston;TX;77058-2722;USA email;internet: b.wolfe@ieee.org title: Robotics Engineer tel;work: 281-461-7886 tel;fax: 281-461-9550 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------39153669E1DCF15E842D4D8B--Article: 12620
Hello, Does somebody know where to find Lattice ispDOWNLOAD cable schematics ? thanks for any help. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member ForumArticle: 12621
Hello, Does somebody know where to find schematics for Lattice isp DOWNLOAD cable ? Thanks for any help. Marko. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 12622
i've seen the synthesizers do things that you wouldn't expect; extra flip-flops that aren't needed and a complete disregard for the users instructions, be default ignoring the designers specification for the 'others' case. some tools may wind up designing poor circuits that a human would not design and that he specifies not to be designed. but the tool, probably to make better "quality of results," ignores. so, some circuits are poor, more resources than necessary. others may be bad circuits, don't meet spec. while i like the hdl's, sometimes it's just plain "faster, cheaper, and better" to use a schematic. rk QFED - the 'f' is for emphasis. ------------------------------------------------------------------------- John L. Smith wrote: > Rick Filipkiewicz wrote: > > > Watching this seemingly eternal schematics vs. HDL argument I find myself, > > typically, agreeing with both sides. Schematics for their intuitive nature, > > at least for datapath stuff - state machines are more problematic. > > Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic, > at least one-hots. If you want to get fancy, the FF > carrying the state can be wrapped in a symbol with one or two > (or more) inputs: enter (for a transitional state active for only > one cycle), enter and exit, enter and hold, choose your own combo's. > The transition logic is usually a simple sum of products applied > to either of the two state control inputs. Almost as easy to read > as a state diagram. Also, you know what it will compile into, as > opposed to one SM -> HDL -> netlist tool I've looked at, > which ended up producing circuits 50% to 100% larger than the > schematic. And a 100% larger circuit is likely to run half-fast. > > Portability --> HDL > Performance --> Schematic > > ------------------------------------------------------------------------ > > John L. Smith <jsmith@visicom.com> > Principal Engineer > Visicom Imaging Products > > John L. Smith > Principal Engineer <jsmith@visicom.com> > Visicom Imaging Products HTML Mail > 1 Burlington Woods Work: 781-221-6700 > Burlington Fax: 781-221-6777 > MA Netscape Conference Address > 01803 Netscape Conference DLS Server > USA > http://www.visicom.com/products/Vigra/index.html > Additional Information: > Last Name Smith > First Name John L. > Version 2.1Article: 12623
To me this argument is similar to C vs assembly debate. People argued that you couldn't write a decent/efficient OS in C; now we have real time embedded kernels which are mostly done in C. Time to market and cost of development (vs cost of square mm of silicon) will make sure that synthesis tools are good enough to be used by vast majority of designer. Rick Filipkiewicz <rick@algor.co.uk> wrote: >Watching this seemingly eternal schematics vs. HDL argument I find myself, >typically, agreeing with both sides. Schematics for their intuitive nature, >at least for datapath stuff - state machines are more problematic. HDL for >speed of writing & modifying random logic. What wins it for me is that the >text nature of HDLs make them amenable to source code revision control, >difficult or impossible with schematics [Correct me if I'm wrong here]. Also >, using lots of instantiation, you can treat HDLs as text based schematics >but the reverse process is awkward. > muzo WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 12624
Thank you! This "update_lib" command is exactly what I needed. Later I found it in an Altera app note. doron nisenbaum wrote in message <362B484A.A7F66F39@chipx.co.il>... >Hi. > >I have no experience with Altera rams, but from question i can guess >that the command you should try in order to read the ram is: > >update_lib <altera library name> syn_ram_8x14_irou.lib > >You can find out the library name using 'list -libraries' command. > >Doron. > >SFCFM Volunteer wrote: > >> Help! >> >> I have used Altera's "genmem" to create a RAM. >> The output files were: >> >> 1. syn_ram_8x14_irou.v which contains the Verilog >> simulation model and the RAM instantiation for >> Synopsys synthesis. >> >> 2. syn_ram_8x14_irou.lib which is to be (somehow) >> inserted to the flex10k-2.db library. >> >> I tried doing a read_lib syn_ram_8x14_irou.lib >> unsuccesfully. Aparently it needs a library header >> to be able to load. I could not find an app-note for >> this in the Altera web site. >> >> Thanks in advance for your help... > > > >-- > >--------------------------------------------------------------------------- -- > Doron Nisenbaum > _/_/_/ _/_/_/_/ _/ > _/ _/ _/ > _/ _/_/_/ _/ Chip Express (Israel) LTD. > _/ _/ _/ P.O.Box 2401 > _/_/_/ _/_/_/_/ _/_/_/_/ Advanced Technology Center > Haifa , Israel 31024 > Chip Express Israel Tel: +972-4855-0011 Ext. 240 > -------------------------------- Fax: +972-4855-1122 > The ASIC Time-to-Market Solution E-Mail: doron@chipx.co.il > http://www.chipexpress.com > > >--------------------------------------------------------------------------- -- > > >
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