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
"rk" <stellare@nospamplease.erols.com> wrote in message news:3BD5D8C9.863F3C48@nospamplease.erols.com... > Hi, > > Perhaps a bit off-topic for an FPGA group but I think the right audience > is here. > > I haven't used ECL in a number of years (silly FPGAs taking up too much > time) but would like to know what the current families (and > manufacturers) are for very high-speed logic, US military/space > qualified, with "reasonable" power levels and worst-case clock > frequencies of 600 MHz, min. I'm looking at some operations such as > synchronous counters, Johnson twisted ring counters, etc. The output of > the logic will be fed into an FPGA (there, that should make this > on-topic :-). Several manufacturers make very high speed ECL families that will meet your needs. Take a look at the ECLinPS, ECLinPS Lite, and ECLinPS Plus families. The first manufacturer is ON Semi: http://www.onsemi.com/pub/prod/0,1824,productsm_Taxonomy_MaxLevel%253D5_SubT ype%253DProduct_LevelName1%253DLogic_LevelName2%253DProduct^20Families,00.ht ml The second manufacturer is Micrel (formerly Synergy): http://www.micrel.com/product-info/ecl_logic.shtml The third manufacturer is Arizona Microtek: http://www.azmicrotek.com/products.htm They can do asics as well. I do not know about military/space qualification avaliability. Daniel LangArticle: 35951
Hi Mike, The Spartan would be driving it's own TDI pin. So if I understand it all correctly then it would be controlling the entire chain from the user I/Os, and it would have to make sure it bypasses itself. Dean Mike wrote: > Dean, > > Would the Spartan-II be driving the TDI of the CPLD, or it's own TDI? If it's the former, this could cause problems. When TMS is common to all the devices (as it would be if you are implementing a single chain) that means all the devices are always in the same JTAG state. If the Spartan-II has loaded the bypass instruction and is in the SDR state, this means it is driving it's TDO pin with whatever is on the TDI pin (delayed by one TCK cycle). If the Spartan-II is also driving the TDI pin of the first CPLD, you will get contention on this signal. If however, the Spartan-II is driving it's <i> own </i> JTAG signals, and the Spartan-II is first in the chain, you will not hit this contention issue. > > HTH, > > MikeArticle: 35952
"Andy Peters" <andy@exponentmedia.deletethis.com> wrote in message > The biggest problem with graphic design entry is that the tools are > always changing. I was thinking more in terms of notation, as in symbols. The power of mathematical notation and its significance in the enabling of thought and expression is important to recognize. A similar thing can be said about the power of notation in other areas of knowledge, such as music. Music can manage and very efficiently document highly complex relationships of pitch, rates, emphasis, volume, synchronisation, etc. --in parallel-- that can be communicated and executed by those schooled in the art with great facility. If you've ever seen the score for an orchestral arrangement you'll know what I mean. I couldn't imagine applying a Verilog/VHDL/C approach to the documentation and/or authoring of a musical work of major (or even medium) complexity. The language itself, and the constructs used, would separate the author so far from the creative process that, if possible at all, the task would be highly inefficient with limited ability to engage in exploration of expression and ideas. Notation is important, we've been fitting the problem to the "limitations" of a keyboard that was invented decades and decades ago who's limited character set has little, if any, relevance to the expression of concepts outside a limited subset of spoken languages on Earth. Better tools, in my microcosm of thinking, have to be based on a system that merges a number of forms of expression of ideas in order to boost productivity and creativity as well as provide an efficient path to the ultimate goal: a working piece of hardware. This could include schematic entry for "big picture" structural description, textual information for descriptive documentation (traditionally, comments in programming) and and "out of the box" symbolic language designed specifically for the discipline at hand. -MartinArticle: 35953
Andy Peters <andy@exponentmedia.deletethis.com> writes: > Do yourself a favor, and don't directly use the Crystal > MCLK/LRCLK/BCLK/data outputs to drive a converter. Use a FIFO in > between, and generate your clocks locally. You'll cut the jitter down. And potentially introduce slips, since your sample rate may not match the source. :-(Article: 35954
On 24 Oct 2001 17:46:59 -0700, Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: >Andy Peters <andy@exponentmedia.deletethis.com> writes: >> Do yourself a favor, and don't directly use the Crystal >> MCLK/LRCLK/BCLK/data outputs to drive a converter. Use a FIFO in >> between, and generate your clocks locally. You'll cut the jitter down. > >And potentially introduce slips, since your sample rate may not match >the source. :-( You would only get slips if there was something wrong with your design. Of course you need a PLL to drive the read clock from the FIFO. It is possible to the FIFO depth indicator as a phase detector. Allan.Article: 35955
Hello everyone! I'm graduated student at university. I want know about JBits. from fundamental to applications please, answer to me. thank you.Article: 35956
Hello, I want to design a very small board to control some LEDs, relays etc. It will be controlled by a serial port (Rx-only). I don't want to use any processor (not even PIC); instead I'd like to implement the control-logic with a CPLD. I would like to use a watch-crystal (32768 Hz) as the clock source; is there any CPLD with built-in crystal oscillator? I don't want to add another chip to the design just for clock-source. Thanks in advance Assaf SarfatiArticle: 35957
Assaf Sarfati wrote: > > Hello, > > I want to design a very small board to control some LEDs, relays etc. It will > be controlled by a serial port (Rx-only). > > I don't want to use any processor (not even PIC); instead I'd like to implement > the control-logic with a CPLD. > > I would like to use a watch-crystal (32768 Hz) as the clock source; is there > any CPLD with built-in crystal oscillator? I don't want to add another chip > to the design just for clock-source. a) If it's controlling LED / Relays, why do you need an OSC at all ? ( unless you want a 1 wire interface.. ) b) If you do need an OSC, there are no PLDs with Low Freq Osc inbuilt, but a good, low cost, companion device is the HEF4541 (SO14). This can do RC osc (saving the Xtal), or 32.768KHz Xtal Osc. ( also usable, but not as good are HEF4060, and HEF40106 ) I have not tried it, but a rail-rail low power opamp in SO8 could handle OSC + comparitor for clocking. -jg -- ======= 80x51 Tools & PLD IP Specialists ========= = http://www.DesignTools.co.nzArticle: 35958
> Why not just buy one of the Crystal Semiconductor (owned by Lattice)
> parts and be done with it?
Already done some designs with Crystal CS8414, also used
Analogs AD1892 (with samplerate converter, yak!), even used
BurrBrowns DF1704 (8times oversampler)
But having all these external parts isn't any point if you have
free space for it in your FPGA.
> Do yourself a favor, and don't directly use the Crystal
> MCLK/LRCLK/BCLK/data outputs to drive a converter. Use a FIFO in
> between, and generate your clocks locally. You'll cut the jitter down.
FIFO is not a problem with some free space in the FPGA. Getting a good
clock system is harder.
> Of course you need a PLL to drive the read clock from the FIFO. It is
> possible to the FIFO depth indicator as a phase detector.
This brings me to another question, anybody done a up/oversampler with
sample rate convertion?(e.g. you don't need to 'lock' on the incoming
signal, just get rid of the jitter on it)
(I haven't done the maths for it yet, but I'm shure it ain't going to be
easy :)
)RST(
Article: 35959Hi, Could anyone give any advice as to which book to get to learn about programming FPGA's. I have Ashenden's 'The Designer's Guide to VHDL'. This is good for learning VHDL, but isn't very instructive as to programming FPGA's with VHDL. I have been designing only with schematics as it is more intuitive than VHDL if you don't have much reference material. Thanks AdrianArticle: 35960
Hello, In my design I need to make a synchronous counter that counts, let's say, till 1000000. (Actual aim for counter is to built in a delay). I do this by the use of integer type signals and with each clock'event I add 1 till I reach the wanted 1000000. When I try to implement this in an FPGA it consumes a very high amount of CLBs and it seems very disastrous for the maximum reachable clock freq. If I would use an unsigned type would it differ a lot? Other tips? Greetz from a newbie, Jerre.Article: 35961
Jerre wrote:
>
> Hello,
>
> In my design I need to make a synchronous counter that counts, let's
> say, till 1000000. (Actual aim for counter is to built in a delay). I
> do this by the use of integer type signals and with each clock'event I
> add 1 till I reach the wanted. When I try to implement this
> in an FPGA it consumes a very high amount of CLBs and it seems very
> disastrous for the maximum reachable clock freq.
When you say that you increment on EVERY clock event that would mean
that there would have to be some complicated logic: normally we only
design things to trigger off one edge of the clock, be iti rising of
falling. This may generate a lot of your logic.
Secondly, by using integers, your counter can in theory go up to 32 bits
of logic, even though you only need 20 bits to get to 1 million. If you
create a subtype of integer with the appropriate range then the
systhesis tool stands a better chance of getting it right.
There may be other problems: posting your code would give people a
better idea.
>
> If I would use an unsigned type would it differ a lot?
Depends whenther you mean the actual type unsigned or the adjective
unsigned. Using natural type instead of integer won't make much
difference. Using a 20-bit unsigned would work better though.
--
___#--- Andrew MacCormack andrewm@tality.com
L_ _| Senior Design Engineer
| | Tality, Alba Campus, Livingston EH54 7HH, Scotland
! | Phone: +44 1506 595360 Fax: +44 1506 595959
T A L I T Y http://www.tality.com
Article: 35962
Hi Adrian,
Try:
Vhdl for Programmable Logic
by Kevin Skahill,
ISBN: 0805895736
It is a great book for beginners in VHDL and has couple of chapters on
Programmable logic (which to be honest I skipped as I am in ASIC
domain).
HTH,
Srinivasan
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
"Noddy" <g9731642@campus.ru.ac.za> wrote in message
news:1003995752.528025@turtle.ru.ac.za...
> Hi,
>
> Could anyone give any advice as to which book to get to learn about
> programming FPGA's. I have Ashenden's 'The Designer's Guide to
VHDL'. This
> is good for learning VHDL, but isn't very instructive as to
programming
> FPGA's with VHDL. I have been designing only with schematics as it
is more
> intuitive than VHDL if you don't have much reference material.
>
> Thanks
>
> Adrian
>
>
>
Article: 35963Jerre <duvister@hotmail.com> wrote in message news:d4b00a9.0110250106.7e81aba6@posting.google.com... > In my design I need to make a synchronous counter that counts, let's > say, till 1000000. (Actual aim for counter is to built in a delay). I Hi Jerre, To count to a value and compare is very wasteful of resources & slow. If you count down (from a programmed value) & act on underflow of the counter then you get the (fast) carry chain of the counter to perform the compare for you; add an extra bit to the counter to monitor this underflow state. You cannot do this with integer type as simulation will fail on integer underflow. I use ieee.numeric_std and type unsigned in my implementation of a signal delay. Delay in clocks (+1 for underflow) and the width of the counter are specified as generics. At 21bits (even to 30+bits), this will be v. v. quick. FredArticle: 35964
fred <x@y.z> wrote in message news:z1SB7.1218$t97.13337@news.uk.colt.net... > To count to a value and compare is very wasteful of resources & slow. If you > count down (from a programmed value) & act on underflow of the counter then > you get the (fast) carry chain of the counter to perform the compare for > you; add an extra bit to the counter to monitor this underflow state. ps: you only need to monitor the (extra) top bit to detect the underflow FredArticle: 35965
phil <p.beylik@libertysurf.fr> wrote in message news:<20011024-16252-677191@foorum.com>... > Hi, > > Somebody has already work with the card rc1000-pp of celoxica We are looking to purchase rc1000 boards from Celoxica for porting alogortihms using Handel-C. What's your rating for the board?Article: 35966
I recently made a presettable synchronous 27 bit counter to implement a delay. It reaches 120MHz clock on an Altera ACEX chip, according to the Altera simulation. It is being used at 80MHz. And yes, the 27 bits are 27 flipflops and the preset are another 27 flipflops. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com Jerre wrote: > > Hello, > > In my design I need to make a synchronous counter that counts, let's > say, till 1000000. (Actual aim for counter is to built in a delay). I > do this by the use of integer type signals and with each clock'event I > add 1 till I reach the wanted 1000000. When I try to implement this > in an FPGA it consumes a very high amount of CLBs and it seems very > disastrous for the maximum reachable clock freq. > > If I would use an unsigned type would it differ a lot? > > Other tips? > > Greetz from a newbie, > > Jerre.Article: 35967
"John Smith" <parps@ic24.net> schrieb im Newsbeitrag news:tsti8a8afas8ce@corp.supernews.com... > Hi, > > According to the Xilinx literature their PCI cores are not synthesisable by > their own XST VHDL compiler. Does anyone know why this is? Has anyone tried > synthesising Xilinx PCI cores using XST? > It's tricky but possible ! If you want to know the details please contact me directly. TobiasArticle: 35968
"Johan Van Dyck" <Johan.Van.Dyck@philips.com> wrote in message news:<3bd6a983$0$7113$4d4efb8e@news.be.uu.net>... > Hi > > * The synth process reads your code and transforms it to known blocks like > mux, adder,... It also unrolls the loops. > * The mapper (implementation) maps the generic blocks from the synth to the > real lay-out from your FPGA. As a generic block could be a '200 to 5 mux', > in the FPGA only '4 to 2 mux' (this is an expample) could exist. Lot's of > 4t02 mux must be cascaded to form the original block. > * After mapping you can simulate a kind of gatelist generated out of the > tool. (We never use that). > *Of course, you need to verify the FPGA after the mapping is programmed > insite. > > Hope this helps you a littel bit > > Johan. > > "Ramnath" <ramnathgoenka@yahoo.com> wrote in message > news:62cc2cff.0110201050.7d89b335@posting.google.com... > > hi, > > > > I am a newbie to this area and slowly picking up things. I am > > using Xilinx foundation series v 1.5 and Model sim. > > > > Alothough i have all these and even using these things, i do not > > fully understand the concept of all. > > > > Could any one tell me what are the various stages in the synthesis > > of FPGA. > > > > To be exact what is done in the synthesis process, implementation > > process, simulation and verification. > > > > What is the difference between simulation done in ModelSim and the > > simulation done in Xilinx itself. > > > > Some one told me Modelsim is for simulation the testbeches ( still > > not clear, please through some light) > > > > Thanks a lot in advance and expecting the reply. > > > > Ramnath Ramanath, As you write, modelsim is effictively suitable for testbenches,of course even for models. I have smatttering of knowledge about xillinx software.So i will leave it to others. The advantages you get with the modelsim are great. For example transport delays,file operation ,and also some other advanced features will not work in . You can even talk with your VHDL designs with C programs. If your design is very big, you can't apply signals through force commands and see output signals. Your testbench should be very exhaustive one. In Some cases, it will be better to have the testbench that applies the signal upon our need and finally tells that your model is correctly functioning or not.Using VHDL advanced features and the modelsim features, the job of getting a good testbench will be easy one. questions welcome, regards, krishnaArticle: 35969
Our application will be targetted to Xilinx SpartanXL XCS30XL-4-BG256C. In Spartan/SpartanXL datasheet v1.6, it says that GCK6 and DOUT is on B19 in a BG256 package. We have too many clocks and we want to use this B19 as clock input. But during the configuration, does it harm that we connect a clock to B19, if the device is master/slave serial? Shall we disable the clock to B19 during the configuration of this device? UtkuArticle: 35970
In a design I'm working on at the moment, I have new data on every rising edge of a 175 MHz clock and I need to transfer it to be synchronous to a 350 MHz clock. No uncertainty in the 350 MHz data is acceptable. To generate the clocks, I have an external 350 MHz source, and I'm using the CLK0 and CLKDV (divided by 2) outputs on a DCM. I'm using a Xilinx 2V6000-5. I have global buffers for each clock, but I expect there will be some skew between the clocks, since the 350 MHz clock is lightly loaded (200-300 FFs), compared to the 175 MHz clock (2500 FFs). So I might violate the hold time on the 350 MHz FFs if I'm not careful. Some things I have considered: 1. Sample the 175 MHz data with the 350 MHz clock directly. Could violate the hold time if there is sufficient skew between the clocks and the logic/net delays are particularly small. Also, I have 68 bits of data, so this isn't too good. 2. Sample the 175 MHz data with the next falling edge of the 350 MHz clock. A half-period of the 350 MHz clock is only 1.429 ns. Allowing for jitter, the FF to FF delay needs to be about 1.3 ns, on all 68 data paths. Plus another 68 paths to get it back to the rising edge, possibly. 3. Generate an enable signal at 175 MHz and sample it using the falling edge of the 350 MHz. Same problem as #2, but with only 1-2 bits. I did try this, with hand placement of the FFs, and got the delay down to 1.41 ns, which is impressive (effectively over 700 MHz performance), but probably not enough. Using the enable signal, the data bits have a full 350 MHz period of setup and hold (less skew). 4. Just do it (like #1), but add some deliberate delays in the data path to try to guarantee that the delays are larger than the clock skew. Deliberate delays could include hand placement to create long net delays, or instantiating LUTs to act as buffers. This could be limited to a single enable bit, with the data bits transferred safely on the next 350 MHz edge. #3 is preferred, but not quite fast enough. #4 seems the next best option, but it makes me a bit uncomfortable. Can anyone add any other suggestions? Or try to convince me that #4 is acceptable, or otherwise? I saw a new Xilinx app note, XAPP265, which described a design for doing an 8:1 SERDES. That design would have a similar requirement to mine. It uses an 1/4 frequency clock instead though, which seems to simplify the problem a bit. thanks, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 35971
If you are using Verilog and Xilinx block ram coregen models for RTL
simulation, the register "mem" in the block ram module contains the data you
want. The register "mem" is an one-dimensional array used internally by the
module for bus matching. You can dump it in what ever format you want,
something like;
reg [width-1:0] ram_data[depth-1:0];
reg [width-1:0] temp;
outfile = $fopen("blockram.dump");
for( addrs = 0; addrs < depth; addrs=addrs+1) begin
for (bits = 0; bits < width; bits= bits+1) begin
temp[bits] = top.l0.l1.block_ram.mem[addrs*width+bits];
end
ram_data[addrs] = temp;
$fdisplay(outfile,"%b", ram_data[addrs]);
end
$fclose(outfile);
Hope this helps,
Jim
"Jack Tai" <jtai@3dsp.com> wrote in message
news:12eb99cf.0110191553.4edd970@posting.google.com...
> Does any one know how to do the memory dump on Xilinx Block RAM? I am
> using Modelsim as my simulation software. I try to do this at RTL,
> Post-synthesis and Post-route simulation.
> Thank you
> Jack Tai
Article: 35972The reason the CLB usage is so high is due to the fact that CLBs are partially used. For example, the report states that you've used 68/200 flops -- what you don't know is how the flops are packed into the CLBs. Each CLB contains two flops, 3 look-up-tables (LUTs), & two groups of muxes. You might have 1 flop per CLB. If you design with the CLB architecture in mind then you can map to both of the flops in each CLB. The same goes for the LUTs in your report. Pat Dave Brown wrote: >Hi all, > Thanks for all the great help so far, this is a great newsgroup! I'm >looking at my Device Utilization Summary in Foundation ISE 4.1, for a >Spartan 05XL, and I'm not sure why the overall CLB utilization is so high >when my other numbers are low, is there some tool setting I'm missing, if >not, what is eating up all my CLBs? Here's the exerpt from the summary: > >Device utilization summary: > > Number of External IOBs 52 out of 80 67% > Flops: 0 > Latches: 0 > > Number of CLBs 87 out of 100 87% > Total Latches: 0 out of 200 0% > Total CLB Flops: 68 out of 200 34% > 4 input LUTs: 137 out of 200 68% > 3 input LUTs: 27 out of 100 27% > > Number of BUFGLSs 5 out of 8 62% > >Thanks, >Dave > >Article: 35973
I think perusing the FPGA vendor's websites, especially the design for
synthesis and applications notes pages will get you farther than a book,
and is likely to be more current.
Srinivasan Venkataramanan wrote:
> Hi Adrian,
> Try:
>
> Vhdl for Programmable Logic
> by Kevin Skahill,
>
> ISBN: 0805895736
>
> It is a great book for beginners in VHDL and has couple of chapters on
> Programmable logic (which to be honest I skipped as I am in ASIC
> domain).
>
> HTH,
> Srinivasan
>
> --
> Srinivasan Venkataramanan
> ASIC Design Engineer
> Software & Silicon Systems India Pvt. Ltd. (An Intel company)
> Bangalore, India, Visit: http://www.simputer.org)
>
> "Noddy" <g9731642@campus.ru.ac.za> wrote in message
> news:1003995752.528025@turtle.ru.ac.za...
> > Hi,
> >
> > Could anyone give any advice as to which book to get to learn about
> > programming FPGA's. I have Ashenden's 'The Designer's Guide to
> VHDL'. This
> > is good for learning VHDL, but isn't very instructive as to
> programming
> > FPGA's with VHDL. I have been designing only with schematics as it
> is more
> > intuitive than VHDL if you don't have much reference material.
> >
> > Thanks
> >
> > Adrian
> >
> >
> >
--
--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: 35974
--------------030202080705070509090007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Another good choice is to look at actel's web site: www.actel.com.
They have an HDL style guide.
Also check out www.exemplar.com. Look at the site map & then go
to the application notes. There will be synthesis tips, etc.
Just one more ...
In the beginning you should concentrate on one FPGA platform. I'm
a Xilinx guy -- but there's also Altera, Atmel, Actel, etc.
The vhdl you design will be "just plain vhdl" at first, but after you
learn your target platform you'll be designing the RTL with
the architecture in mind.
Patrick.
Srinivasan Venkataramanan wrote:
>Hi Adrian,
> Try:
>
>Vhdl for Programmable Logic
>by Kevin Skahill,
>
>ISBN: 0805895736
>
>It is a great book for beginners in VHDL and has couple of chapters on
>Programmable logic (which to be honest I skipped as I am in ASIC
>domain).
>
>HTH,
>Srinivasan
>
>--
>Srinivasan Venkataramanan
>ASIC Design Engineer
>Software & Silicon Systems India Pvt. Ltd. (An Intel company)
>Bangalore, India, Visit: http://www.simputer.org)
>
>
>"Noddy" <g9731642@campus.ru.ac.za> wrote in message
>news:1003995752.528025@turtle.ru.ac.za...
>
>>Hi,
>>
>>Could anyone give any advice as to which book to get to learn about
>>programming FPGA's. I have Ashenden's 'The Designer's Guide to
>>
>VHDL'. This
>
>>is good for learning VHDL, but isn't very instructive as to
>>
>programming
>
>>FPGA's with VHDL. I have been designing only with schematics as it
>>
>is more
>
>>intuitive than VHDL if you don't have much reference material.
>>
>>Thanks
>>
>>Adrian
>>
>>
>>
>
>
--------------030202080705070509090007
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
Another good choice is to look at actel's web site: www.actel.com.<br>
They have an HDL style guide. <br>
<br>
Also check out <a class="moz-txt-link-abbreviated" href="http://www.exemplar.com">www.exemplar.com</a>. Look at the site map & then go<br>
to the application notes. There will be synthesis tips, etc.<br>
<br>
Just one more ...<br>
<br>
In the beginning you should concentrate on one FPGA platform. I'm<br>
a Xilinx guy -- but there's also Altera, Atmel, Actel, etc.<br>
<br>
The vhdl you design will be "just plain vhdl" at first, but after you <br>
learn your target platform you'll be designing the RTL with <br>
the architecture in mind.<br>
<br>
Patrick.<br>
<br>
Srinivasan Venkataramanan wrote:<br>
<blockquote type="cite" cite="mid:9r8ocq$lad@news.or.intel.com">
<pre wrap="">Hi Adrian,<br> Try:<br><br>Vhdl for Programmable Logic<br>by Kevin Skahill,<br><br>ISBN: 0805895736<br><br>It is a great book for beginners in VHDL and has couple of chapters on<br>Programmable logic (which to be honest I skipped as I am in ASIC<br>domain).<br><br>HTH,<br>Srinivasan<br><br>--<br>Srinivasan Venkataramanan<br>ASIC Design Engineer<br>Software & Silicon Systems India Pvt. Ltd. (An Intel company)<br>Bangalore, India, Visit: <a class="moz-txt-link-freetext" href="http://www.simputer.org">http://www.simputer.org</a>)<br><br><br>"Noddy" <a class="moz-txt-link-rfc2396E" href="mailto:g9731642@campus.ru.ac.za"><g9731642@campus.ru.ac.za></a> wrote in message<br><a class="moz-txt-link-freetext" href="news:1003995752.528025@turtle.ru.ac.za">news:1003995752.528025@turtle.ru.ac.za</a>...<br></pre>
<blockquote type="cite">
<pre wrap="">Hi,<br><br>Could anyone give any advice as to which book to get to learn about<br>programming FPGA's. I have Ashenden's 'The Designer's Guide to<br></pre>
</blockquote>
<pre wrap=""><!---->VHDL'. This<br></pre>
<blockquote type="cite">
<pre wrap="">is good for learning VHDL, but isn't very instructive as to<br></pre>
</blockquote>
<pre wrap=""><!---->programming<br></pre>
<blockquote type="cite">
<pre wrap="">FPGA's with VHDL. I have been designing only with schematics as it<br></pre>
</blockquote>
<pre wrap=""><!---->is more<br></pre>
<blockquote type="cite">
<pre wrap="">intuitive than VHDL if you don't have much reference material.<br><br>Thanks<br><br>Adrian<br><br><br><br></pre>
</blockquote>
<pre wrap=""><!----><br><br></pre>
</blockquote>
<br>
</body>
</html>
--------------030202080705070509090007--
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