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
My name is Scott Glasrud, and I am running for the New Mexico State Senate
during the 1996 elections. One of the reasons I have chosen to run is to combat
the
proposed state and federal regulations of the Internet. As you know, the
Internet
was never designed to be regulated! It was designed to allow communications in
the event of anuclear war or a major catastrophe. I OPPOSE REGULATION, and if
elected
will fight to preserve your constitutional rights. HOWEVER, I NEED YOUR HELP!
I am asking each person who reeives this message to send $5.00 to the
Scott Glasrud Campaign Committee. If we pull together, we CAN protect our first
amendment rights! HELP ME show the politicians the POWER behind this
important NETWORK. Please send contributions to:
The Scott Glasrud Campaign Committee
11024 Montgomery Blvd. NE, Suite 179
Albuquerque, New Mexico 87111
Thank you!
Article: 1951On 22 Sep 1995, Robert Tjarnstrom wrote: > I would say that it is necessary to see hardware architecture when you design. > Otherwise, you are incapable of making acceptable design solutions. Performance and > product properties are determined by choise of algorithm, architecture (at many > levels) and technology. this sounds rather like a call for HDLs to allow the designer to make more architectural decisions. a paper presented by Satnam Singh of my department at the last FPGAs for Custom Computing Machinery (FCCM) conference describes an alternative HDL called Ruby which allows the designer to work with both behaviour and architecture. this paper, others, and more information on the Ruby HDL can be found at: http://www.dcs.gla.ac.uk/~satnam/ :-jonathan -- Jonathan AH Hogg, Computing Science, The University, Glasgow G12 8QQ, Scotland. jonathan@dcs.gla.ac.uk http://www.dcs.gla.ac.uk/~jonathan (+44)141 3398855x2069Article: 1952
Is there any cheap fpga design package on the market which will do Xilinx 3000 series? Please email replies. TIA, Nico CoeselArticle: 1953
Yup! PC-Card side - if you got it, I want it. Hope to hear from you! Rolande Kendal <The sun shines on everyone!>Article: 1954
From: Zalman Stern <zalman@macromedia.com>
>Can either of you explain what in the design contest made it impossible to
>use "natural VHDL?" My guess is that the test scaffold provided defined an
>interface to the chip in terms of raw bit vectors which caused problems.
>I'm asking because I'm not sure if this is an issue of the way the contest
>was specified, or that this particular task is ill suited to VHDL. Would
>it have been possible to write a simple VHDL specification if the test
>harness was different? Would it have allowed one to syntehsis low-level
>hardware and do the timing simulation?
The fact that none of the VHDL based designers could build a 9-bit up-by-3
down-by-5 counter with parity, carry & borrow while 8 out of 9 of the
Verilog based designers could was a big surprize to me and the others who
helped create the contest. The main reason that I chose std_logic data
types for the VHDL designer's required interface was that it *should* be
*very* familiar to any hardware designer who has done synthesis plus these
data types are very synthesis friendly. Yes, Verilog has built in xor
reduction functions that make the parity tree easy to model; but the
common VHDL libraries have the XOR_REDUCTION operator available, too!
Carry & borrow also had no special advantages in either language -- the
designer *still* had to think about what he was doing instead of just
assuming some vague high level abstraction will build what you want.
I really don't think choosing std_logic helped nor hindered the VHDL
contestants.
From: Zalman Stern <zalman@macromedia.com>
>Conceptually, it seems to me that you have to get down to low-level
>hardware sooner or later. I understand that synthesis can reduce
>high-level descriptions to low-level constructs and I understand that
>high-level languages can abstract many of the details for the
>designer. I don't understand whether VHDL can express this counter
>directly in a high-level way. If it cannot, it seems that the design
>contest points out a serious flaw. (I.e. if your goal is to develop a
>working counter for timing simulation, then VHDL isn't the right
>tool.) If it can be done in the high-level language, then we get into
>how well the synthesis works. (Since I presume VHDL synthesis has to
>do more work than Verilog synthesis.)
To me a hardware description language is *supposed* to be used to design
hardware -- not model the human brain or the movement of the earth's
crust -- but state machines, DSP designs, data paths, raw gates, etc.
I fully understand the philosphy of moving to higher levels of abstraction
and think its a beautiful concept on paper. But, then again, Communism
is quite beautiful in theory, too. Both make for great coffee shop
discussions but it's the actual attempt at implementing either idea that
seems to be fairly impractical (and painful) in most cases these days.
Regarding the concern that VHDL might be harder to synthesize; I really
don't see that much if you restrict yourself to using the synthesizable
subset of VHDL (steering clear of files & records, etc.) as most experienced
designers do. It's when you get some Verilog or VHDL which was written by
someone who is completely hardware ignorant and then try to synthesize it
is when you get into serious trouble!
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 3713 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 1955In article <436p16$a1m@mksrv1.dseg.ti.com>, Todd says: > >does anyone have a macro or VHDL code to implement >a UART? I'm using an Actel 10 or 12 series fpga. >I'm really more interested in receiving serial code >than transmitting. > The April 1990 version of Actel databook has an example of a schematic of a UART. It utilizes <200 logic modules of a 10 series part. The logic for the reciever portion looks fairly straight forward. Just feed in a X16 receive clock, and watch for the mark-space transition to start the sampling. I looked in all the recent databooks and the example was not present. If you cannot find it, then email me, and I will try to get you a copy of the 11 pages. EricArticle: 1956
In response to the person that asked about implementing a 40MHZ controller in an FPGA; I have to say that's probably impossible given the speed and gate count of current devices. Gate-wise AT&T parts with FPGA gate counts around 40K (according to AT&T) may translate to 20-25K ASIC gate count. With high gate utilization your max. speed will probably fall below 10MHZ. Kayvon Irani Lear Astronics Los AngelesArticle: 1957
I'd like to know if any brave designer out there has tried to implement an FFT algorithm in an FPGA. Any one has experience with Mentor/Synopsys tools that take your algorithms and output VHDL synthesizable code? Regrards, Kayvon Irani Lear Astronics Los AngelesArticle: 1958
In article <43ugb7$amg@euas20.eua.ericsson.se>, ekatjr@eua.ericsson.se (Robert Tjarnstrom) writes: |> In article <43fgn7$45f@news.Belgium.EU.net>, Jan Decaluwe <jand> writes: |> >jcooley@world.std.com (John Cooley) wrote: |> > |> > |> >>I personally tend to see hardware when I design hardware, |> > |> >This argument is widely used against design methodologies that rely |> >on higher levels of abstration. I believe it is misleading. It is the |> >same argument that schematic entry addicts use(d) against RTL synthesis. |> >However, I feel safe to assert, John, that you're a convicted synthesis user!! |> > |> |> Am I correct if I understand that you indicate that the designer should not tend |> to see HW while designing, but rather focus on modeling the functionality at as |> high abstraction level as possible? If so, I could not disagree more. |> |> I would say that it is necessary to see hardware architecture when you design. |> Otherwise, you are incapable of making acceptable design solutions. Performance and |> product properties are determined by choise of algorithm, architecture (at many |> levels) and technology. Power dissipation/consumption is a physical activity, and |> in order to fulfil power requirements I would say it is necessary to see HW while |> designing. |> |> Prediction on power dissipation must be made for all architectural decisions and in |> order to make such prediction you must see hardware. If not you may end up with drastic |> violation on important properties. (A cellular telephone with a talk time of 5 min |> would probably be hopless to sell even for Microsoft :-). |> |> Robert Tjarnstrom |> |> |> Robert, I do not agree with you, at least not totally. I think the situation can be compared to writing software or rather embedded software. You won't write this software - except for the very critical parts - in assembler. You will write it in a higher-level language which gives you more readability, maintainibility, chances for reuse. The knowledge of the possibilities and limitations of the hardware the program will run on is needed of course : You must have an idea about the number of cycles, the speed, the memory usage. I think most of the programmers have this idea, but they don't think or analyze it very explicitly. It is just an implicit knowledge grown by experience. For VHDL, written on a higher level, it is the same. You mustn't write it the hardware way, but of course you need an idea about gate-use, speed, power ... The more critical parts will then be written on a lower VHDL-level (just as assembler in software) but the main part can be written on high-level. According to me this is no reason to reject the approach of the more abstract types. I wouldn't say 'Think hardware' but rather 'Don't think too software'. Jos De Laender ASIC designer. Alcatel Bell - SH144 -> Those ideas are not necessarily those of Alcatel Bell <-Article: 1959
In article <DFECGw.B87@world.std.com>, jcooley@world.std.com (John Cooley) writes: |> On 22 Sep 1995, Robert Tjarnstrom wrote: |> >I would say that it is necessary to see hardware architecture when you |> >design. Otherwise, you are incapable of making acceptable design |> >solutions. Performance and product properties are determined by choise |> >of algorithm, architecture (at many levels) and technology. |> |> These are my sentiments exactly! Yes, I've heard all the claptrap about |> "moving to higher levels of abstraction" but, in the end, it's just |> going to be all gates in an ASIC. If you lose sight of that fact, you're |> in fundamental trouble. |> Yes, just like all software, be it written in C,C++,Pascal,Assembler, ADA,Cobol,Fortran ends up in binary codes which are run on a host processor with a limited speed and a limited memory area. Did this prevent people from writing in other than assembly-level languages ? Jos De Laender ASIC designer. Alcatel Bell - SH144 -> Those ideas are not necessarily those of Alcatel Bell <-Article: 1960
Does anyone know whether and where I can get the PREP benchmarks? Are they publicly available? Thanks in advance, HermanArticle: 1961
Intergraph Electronics is on the move and growing. We are in need of a AE for the Boston area. Must have experience in CAE tools (ESDA, VHDL, Verilog, Schematics, Digital Simulation, etc.) Respond via email: dcui@ingr.com Dan Cui Intergraph ElectronicsArticle: 1962
Problem solved! Thanks to everyone who posted and e-mailed. Turns out that it was pilot error, although I can't find anything in the literature to support it. When compiling the part you must set the correct download mode in two different but very similar menus. The appropriate mode must be selected through: "Assign -> Device -> Device Options -> FLEX 8000 Device Options" and in "Assign -> Global Project Device Options -> FLEX 8000 Device Options" After doing this and recompiling it worked fine. Don't know why I didn't have the same trouble with the 8452A. Thanks to Jenny at Altera for coming up with this one. LArticle: 1963
In article <DEynz9.KLt@emr1.emr.ca>, methot@ccrs.emr.ca says... > >I am presently starting a project using emitter coupled logic (ECL). >Does anyone know of a manufacturer of ECL fpga. The data rate that must >be achieved is 150 mbits/sec, and the input voltage is ECL. One of the >task is to be built a P-N sequence decoder. Thanks. > Thank you to everyone that responded. Only found Philips that had a programmable ecl device. For information, another company AMCC has an ASIC ecl family AMCC Q20000. SimonArticle: 1964
In article <1995Sep25.090210@btmp09.be>, jdla@btmp09.be (jos de laender sh144 7461) writes: > >I do not agree with you, at least not totally. I think the situation >can be compared to writing software or rather embedded software. > >You won't write this software - except for the very critical parts - >in assembler. You will write it in a higher-level language which gives >you more readability, maintainibility, chances for reuse. >The knowledge of the possibilities and limitations of the hardware >the program will run on is needed of course : You must have an idea >about the number of cycles, the speed, the memory usage. >I think most of the programmers have this idea, but they don't think >or analyze it very explicitly. It is just an implicit knowledge grown >by experience. > >For VHDL, written on a higher level, it is the same. You mustn't write >it the hardware way, but of course you need an idea about >gate-use, speed, power ... The more critical parts will then be >written on a lower VHDL-level (just as assembler in software) but the >main part can be written on high-level. > >According to me this is no reason to reject the approach of the more >abstract types. I wouldn't say 'Think hardware' but rather 'Don't >think too software'. > >Jos De Laender >ASIC designer. >Alcatel Bell - SH144 > >-> Those ideas are not necessarily those of Alcatel Bell <- 1. I do not see why to move over to software while discussing the need to see hardware while making architectural decisions. However, if we do that we should look at hard real time systems, since hardware is indeed a hard real time system. As far as I know hard real time systems are coded in assembler or assembler like languages. One reason for that is the timing verification. You need to be 100% sure to meet all the deadlines, and the only way to do that is to count the instructions and their execution times. Linear functions will indeed simplify the timing verification. The situation is pretty much the same as for design of hardware. I you have plenty of time to meet your deadlines, plenty of memory and plenty of execution power you could of course use C++. (Then we are at the performance issues). 2. Do not mistakenly assume that I am against high level modelling. On the contrary I think that is clearly advantageous for a HW project. There are many reasons for that. However, I think I would prefer a functional language for that purpose. In imperative languages you need to deal with what to do, how to do it and also memory management, while using a functional language you can focus on declaring the desired functionality. But still, while doing the architectural decisions you need to see hardeware in order to accomplish desired product performance and characteristics. Robert TjarnstromArticle: 1965
nctnico@cistron.nl (Nico Coesel) wrote:
>Is there any cheap fpga design package on the market which will do
>Xilinx 3000 series? Please email replies.
>
>TIA,
>Nico Coesel
While I don't know of any 'free' development software for the
XC3000,
I can certainly recommend a low-cost system.
Xilinx offers two low-cost packages that cover the lower-density
FPGAs and all of our EPLDs. Both include the appropriate schematic
libraries and simulation files.
Both systems sell for less than US$1,000. I can also recommend a
Xilinx EPLD system that sell for less than US$100.
You can receive full details through your local Xilinx
representative
(which I believe is SEI Rodelco in the Netherlands based on your
E-mail address). You can contact them at:
SEI Rodelco BV (The Netherlands)
TEL: 31-76-784911
FAX: 31-76-710029
FOR ORCAD:
---------
If you are using OrCAD, then you would want the DS-OR-BAS-PC1
package.
FOR VIEWLOGIC:
-------------
If you are using VIEWlogic, then you would want the DS-VL-BAS-PC1
package.
If you do not have either OrCAD or VIEWlogic, Xilinx also sells an
integrated VIEWlogic system that includes the schematic editor and
simulator. This is called a DS-VLS-BAS-PC1 and sells for less than
US$3,000.
FOR XILINX EPLDs:
----------------
A low-cost package called a DS-550-PC1 support all the Xilinx
XC7200A
and XC7300 family EPLDs and sells for less than US$100.
NOTE: Stay tuned for upcoming announcements on low-cost software
solutions from Xilinx.
Article: 1966twtmail@twt.co.il wrote: > >I'm using an EPM5016 in a small project. >I'm using 4 i/o pins for 2 NOT gates osc. > >The component is getting very very hot (after about 5 min.) > >Does anybody knows why? > >Thanks in advance. > >R.H > I hate to state the possible, but have you checked to make sure VCC and GND aren't reversed? BTW, the 5000 series ceramics will run hot (especially their old state machine chip) under certain conditions i.e., fast clock. -- andrewArticle: 1967
I just got through with a design that has entirely toooooo many chips on it and want to investigate FPGA's and PLD's. Can someone tell me what the difference is and why I would use one over the other to put a lot of my and, or, flipflops, counters into?? Thanks Terry email internet@siu.eduArticle: 1968
On 25 Sep 1995, Robert Tjarnstrom wrote: > As far as I know hard real time systems are coded in assembler or assembler like > languages. One reason for that is the timing verification. You need to be 100% sure > to meet all the deadlines, and the only way to do that is to count the instructions > and their execution times. Linear functions will indeed simplify the timing > verification. The situation is pretty much the same as for design of hardware. or you use a high-level language designed for real-time systems. one that allows you to specify the architecture of the system (such as the size and shape of device registers), respond to interrupts in a controlled manner, manage concurrency with deadlines, do exception handling, and produce memory and type-safe programs. you cannot write any seriously sized system in assembler and be sure of its operation. it has been shown that a programmer produces approximately seven lines of working tested code a day, in _any_ language. if you use a rich language then you can get a lot more for those seven lines than if you use assembler. assembler is something one resorts to, not chooses. for a long time a lot of computer scientists grumbled about the old art of writing machine code being lost and the inefficiency of high-level languages. however, the world moves on. it comes down to shipping a working product on time or not. just like compilers, synthesisers are steadily improving. we are still at the beginning of understanding how to design hardware systems using abstract specifications. but as hardware/software co-design becomes more and more important, so will hardware/software co-synthesis. just as in computing you must realise that in the future ASICs will not be designed by people who know all about transistor models, but by people who can analyse a problem and specify it in an HDL. :-jonathan -- Jonathan AH Hogg, Computing Science, The University, Glasgow G12 8QQ, Scotland. jonathan@dcs.gla.ac.uk http://www.dcs.gla.ac.uk/~jonathan (+44)141 3398855x2069Article: 1969
In article <1995Sep25.090210@btmp09.be>, jdla@btmp09.be (jos de laender sh144 7461) writes: ... > Robert, > > I do not agree with you, at least not totally. I think the situation > can be compared to writing software or rather embedded software. > > You won't write this software - except for the very critical parts - > in assembler. You will write it in a higher-level language which gives > you more readability, maintainibility, chances for reuse. > The knowledge of the possibilities and limitations of the hardware > the program will run on is needed of course : You must have an idea > about the number of cycles, the speed, the memory usage. > I think most of the programmers have this idea, but they don't think > or analyze it very explicitly. It is just an implicit knowledge grown > by experience. > > For VHDL, written on a higher level, it is the same. You mustn't write > it the hardware way, but of course you need an idea about > gate-use, speed, power ... The more critical parts will then be > written on a lower VHDL-level (just as assembler in software) but the > main part can be written on high-level. > > According to me this is no reason to reject the approach of the more > abstract types. I wouldn't say 'Think hardware' but rather 'Don't > think too software'. > > Jos De Laender > ASIC designer. > Alcatel Bell - SH144 > > -> Those ideas are not necessarily those of Alcatel Bell <- I don't believe that this comparison is correct, however attractive it may be. By and large, all major software programming languages (C, C++, Pascal, Modula-2, etc) provide abstractions that are good matches to the underlying machine code. Your variables, loops etc will still exist in pretty much the same form in the compiled code, though some reordering may have taken place. The compiler is not doing any magic; in fact, excluding the optimizer, the code generation for a modern programming language tends to be a relatively simple process. This is not true, I believe, for VHDL (and even, to some extent, to Verilog). These languages provide abstractions to an event simulator model, not to hardware! Not only is this not a good match to what, in the end, is the desired product (a working chunck of HARDWARE), but also gets in the way of actually trying to produce that hardware. While I worked at IBM (TJ Watson) we conducted some studies that showed that VHDL designs tended to take 3-10x as long to produce and generated 2-4x as many gates as the same designs produced using an internal design language. Even designer skill didn't account for as much variation! True, part of this could be accounted by the variation in the tools themselves, but this too is part of the problem: VHDL and Verilog synthesis must perform some "magic" (state extraction, resource allocation, ...) to transform those languages into hardware. There isn't a trivial mapping of a description to hardware, unlike the software equivalent. Speaking for myself and not for my company, Joao ============================================================================== Name : Joao M C Geada Phone: (508) 262 6225 Email: joao@cadence.com Fax: (508) 262 6636 Post : Cadence Design Systems, 270 Billerica Rd, Chelmsford MA 01824-4140 ==============================================================================Article: 1970
Hi all,
I wonder if I can glean any pointers from you about the following...
(1) Alliance - I just downloaded it (have advice for those doing the same)
is there a route thru the prog for fpga design that works well
are there any significant shortcommings?
(2) I need to layout >20 decade counters (and a bunch of nor gates) on an
fpga - any good ideas as to the optimal choice for a chip?
(3) anyone got some good VHDL code for a decade counter (!)
much thanks, Mathew Lamb
Article: 1971herman@amc.ece.cmu.edu (Herman Schmit) writes :- >Does anyone know whether and where I can get the PREP benchmarks? Are >they publicly available? If you have WWW access try http://www.prep.org/ T.H.Article: 1972
In article <449ccd$jhf@rana.usc.edu> lamb@rana.usc.edu (Mathew J. Lamb) writes:
> (3) anyone got some good VHDL code for a decade counter (!)
Dunno how good it is, but I extracted this from one of my designs. I probably
introduced some errors in the process; I can't test it without rebooting to
DOS/Windows.
entity decade_counter is
port (
clock: in bit;
reset: in bit; -- synchronous reset;
preset: in bit; -- synchronous preset;
data: in bit_vector (3 downto 0);
count: buffer bit_vector (3 downto 0);
);
end decade_counter;
use work.int_math.all;
architecture arch_decade_counter of decade_counter is
signal num: integer range 0 to 15;
begin
proc1: process (clock) begin
if (clock'event and clock = '1') then
if (reset = '1') then
count <= 0;
elseif (preset = '1') then
count <= data;
elseif (count < 9) then
count <= count + 1;
else
count <= 0;
end if;
end process;
end arch_decade_counter;
Article: 1973In <4454u5$l1n@marina.cinenet.net> kirani@cinenet.net (kayvon irani) writes: > > In response to the person that asked about implementing a 40MHZ > controller in an FPGA; I have to say that's probably impossible > given the speed and gate count of current devices. Gate-wise AT&T > parts with FPGA gate counts around 40K (according to AT&T) may > translate to 20-25K ASIC gate count. With high gate utilization > your max. speed will probably fall below 10MHZ. > > Kayvon Irani > Lear Astronics > Los Angeles It depends upon what fraction of the gates are datapath vs. control. Assuming the majority implement datapath functions, and with careful design, contemporary FPGAs should provide adequate capacity and perhaps acceptable speed. For instance, the datapath of a 32-register 32-bit pipelined RISC can fit nicely in the "left half" (10 of 20 columns of CLBs) of a XC4010. In my (paper) design, I use ten columns of CLBs, each 16 CLBs "tall"; ((FG denotes application of F and G logic function generators, FF denotes application of flipflops)): 1. FG (as 32x1 SRAM): reg file copy "A", even bits 2. FG (as 32x1 SRAM): reg file copy "A", odd bits 3. FG: multiplexor (of reg file A value or result bus forward); FF: latch of operand "A". 4. FG (as 32x1 SRAM): reg file copy "B", even bits 5. FG (as 32x1 SRAM): reg file copy "B", odd bits 6. FG: multiplexor (of reg file B value or sign extended 16-bit immediate from instruction register); FF: latch of operand "B". 7. FG: logic unit (A&B, A|B, A^B, A&~B); FF: latch of "result bus". The latter "write back" value is fed to the data-in ports of the two copies of the register file in columns 1-2 and 4-5. 8. FG: adder (A+B, A-B); FF: PC register 9. FG: multiplexor (of adder and incremented PC value, feeds PC register and MAR (from an idea from Philip Fredin)); FF: instruction register 10. FG: incrementor (of PC register); FF: memory address register The "result bus" is a 3state bus driven by tbufs at the adder, logic unit, MAR mux (PC), and "data in" (from RHS of the 4010) columns. For sign or zero extended byte and halfword loads, another column of tbufs drives 0s or 1s appropriately. In addition, shift/rotate left or right 1, 2, or 4 bits uses 6 other columns of tbufs. (This design also uses tbufs in the right half of the chip to do byte and halfword extraction/alignment. For instance, for a store-byte to address 0x000003, the byte of data exits the datapath on bits D[7:0] and is copied up to D[31:24] by tbufs.) So, even half a "10,000 gate" 4010 has adequate capacity for a respectable RISC datapath. As for speed, 16 M instructions/s is doable in a 4010-5. One critical path in the above design is from A and B operand registers, through the 32-bit ripple carry adder, through tbufs onto the result bus, and through the register forwarding multiplexor back to the A operand register. That's something like 3 ns + 33 ns + 10 ns + 5 ns + <10 ns routing delay = ~60 ns = 16 MHz. In straight XC4010-5's, another speed issue regards the register file made from SRAMs. At 16 MHz, there is 60 ns to write back a result and read new operand(s). The above design uses a glitch generator approach to create the SRAM write pulse, a technique Xilinx does not advocate. However, with the new 4000E series parts, Xilinx introduces synchronous SRAMs. Based upon the 4000E spec sheet, the -3 parts are characterized with a Twcts write cycle time of 14.4 ns, so you could do a write and a read in 25 ns (as you require for 40 MHz) or, more straightforwardly, 30 ns/33 MHz. If you need more speed and fewer registers, the dual port configuration would permit concurrent register file write and read access and thus 60+ MHz operation. The 4000E also seems to have doubled the speed of the fast carry logic and so the above 4010-5 datapath could probably run at 30-40 MHz in a 4010E-3. However, I don't yet have the 4000E design software, I'm quoting from spec sheets, I don't know if the 4000E parts are generally available, etc., etc. Your mileage may vary. Jan Gray Redmond, WA // brand new parent, software developer, electronics hobbyistArticle: 1974
In article <Pine.SUN.3.91.950926102636.12680L-100000@switha>, Jonathan AH Hogg <jonathan@dcs.gla.ac.uk> writes: > >or you use a high-level language designed for real-time systems. one that >allows you to specify the architecture of the system (such as the size >and shape of device registers), respond to interrupts in a controlled >manner, manage concurrency with deadlines, do exception handling, and >produce memory and type-safe programs. you cannot write any seriously >sized system in assembler and be sure of its operation. > If you have sifficient time available you could use any language I guess. The problems show up when you do not meet the deadlines. You can follow two paths. A. you make an analysis resulting in an implementation you can show will work, then you code in assembler. B. You implement in a high-level language. Then you start an iteration of re-coding and re-verifying. If you are lucky you will finally meet the deadlines. I do not find the latter path advantageous, but rather frustrating. You have given away control of what you are doing. What you can do following path B is to lower performance of the product so you do not have to iterate too much, which I guess is the common solution. That may also be the right way to go if customer satisfaction can be fulfilled. (We are indeed moving away from the original issue of making architectural decision in hardware design). >it has been shown that a programmer produces approximately seven lines of >working tested code a day, in _any_ language. if you use a rich language >then you can get a lot more for those seven lines than if you use >assembler. > If low number of code lines is essential then everybody should be using functional languages. There you have a significant reduction of code lines. However, we do not see many applications coded in functional languages. There must be a reason for that. Anyone has an idea why?? Poor performance ?? >assembler is something one resorts to, not chooses. for a long time a lot Certainly, if I can solve a problem using, for instance, ML instead of assembler I do it. (Actually, it was a long time ago since I used assembler myself). > >just like compilers, synthesisers are steadily improving. we are still at >the beginning of understanding how to design hardware systems using >abstract specifications. but as hardware/software co-design becomes more >and more important, so will hardware/software co-synthesis. just as in >computing you must realise that in the future ASICs will not be designed >by people who know all about transistor models, but by people who can >analyse a problem and specify it in an HDL. > Tools are clearly better on logic minimization and should of course be used for that. However, I have not seen any tool good at making architectural trade-offs and solutions. Robert Tjarnstrom
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