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
Jonathan Bromley wrote: > On Tue, 20 Jan 2009 21:45:05 -0800 (PST), rickman wrote: > >> There was another company called Plus Logic but I really just can't >> recall the structure of their devices. But I'm pretty sure they >> wern't 4 LUTs. > I believe they had a CPLD-like structure. They were absorbed > by ??Altera after achieving some reasonable sales. The bottom of http://www.fpga-guide.com/overview/overview.html says it is Xilinx. BTW, it seems that CPLD-based FPGA are not very succsessful (and I wouldn't use them unless paid really really well). OTOH has anybody read about the "upcoming" memristor-based FPGA ? -- http://ygdes.com / http://yasep.orgArticle: 137526
maverick > Hi, > I am trying to program Xilinx Virtex-5 PCI Express Development kit > with Digilent USB programming cable with Digilent suuported > programming software. So far I have not been able to program the FPGA. > Does this cable or the software suuport Virtex5 series FPGA? Is there > a link to those listed FPGA devices supported by Digilent USB cable > and accompanied software ? > > > Thanks Have you tried contacting digilent at support@digilentinc.com? I would suspect that their software only supports Digilent boards. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis SynthWorks VHDL Training http://www.synthworks.com A bird in the hand may be worth two in the bush, but it sure makes it hard to type.Article: 137527
Brian Drummond wrote: > The other fine grained one was of course Xilinx's own XC6200, originally > developed in Edinburgh by Algotronics (bought out by Xilinx). Much loved > by researchers because every detail of configuration and routing was > made public; if there was ever a chance of a completely open-source > toolchain, that was it. I believe the basic unit of logic was a 4-LUT > and FF, nothing fancy. Oh, that is an interesting topic ! I have been told that today, 90% of the investments of FPGA vendors go to SW design. Open Source is maybe a solution, since it has evolved a lot in the last years. Though I know pretty well that current Open Source EDA tools suck. But I would like to think in the long term. And with all those oooold FPGA-related patents going to the public domain, new opportunities appear, unlike 5 or 10 years ago... > Consider that with current FPGAs, the area occupied by logic is dwarfed > by the routing area. With fine grained logic that problem must be about > an order of magnitude worse. Factor in the optimisation opportunities > that more complex logic blocks give you; from hard-wired fast carry > chains all the way up to multipliers or DSP units, and you can see why > the trend is towards coarser grained logic. I have read that 4-LUT based ASICs with metal-layer customisation are faster and denser, for this reason : interco transistors that take roughly 80% of the surface are reduced a lot. Something I have learnt only recently... > I would expect to see basic units like 8-bit blocks, almost PLD-like ? > with enough > resources that you could fit a Z80 into half a dozen, in a generation or > two. Forty thousand of them, as well as the block memory, I/O, DSP and a > few ARMs or PPCs to supervise the lot. One annoying thing is that I see a lot of families with multipliers. why don't they simply provide adders too ? multiplies take a lot of resources, sure, but adders are everywhere... > Time to dig out the old bit-slice databooks again? History rhymes again :-) Thanks for the insights, > - Brian yg -- http://ygdes.com / http://yasep.orgArticle: 137528
On Jan 21, 8:14=A0pm, whygee <why...@yg.yg> wrote: > Brian Drummond wrote: > > The other fine grained one was of course Xilinx's own XC6200, originall= y > > developed in Edinburgh by Algotronics (bought out by Xilinx). Much love= d > > by researchers because every detail of configuration and routing was > > made public; if there was ever a chance of a completely open-source > > toolchain, that was it. I believe the basic unit of logic was a 4-LUT > > and FF, nothing fancy. > > Oh, that is an interesting topic ! > > I have been told that today, 90% of the investments of FPGA vendors > go to SW design. Open Source is maybe a solution, since it has evolved > a lot in the last years. Though I know pretty well that current Open Sour= ce EDA > tools suck. But I would like to think in the long term. > And with all those oooold FPGA-related patents going to the public domain= , > new opportunities appear, unlike 5 or 10 years ago... > > > Consider that with current FPGAs, the area occupied by logic is dwarfed > > by the routing area. With fine grained logic that problem must be about > > an order of magnitude worse. Factor in the optimisation opportunities > > that more complex logic blocks give you; from hard-wired fast carry > > chains all the way up to multipliers or DSP units, and you can see why > > the trend is towards coarser grained logic. > > I have read that 4-LUT based ASICs with metal-layer customisation > are faster and denser, for this reason : interco transistors that > take roughly 80% of the surface are reduced a lot. > Something I have learnt only recently... > > > I would expect to see basic units like 8-bit blocks, > > almost PLD-like ? > > > with enough > > resources that you could fit a Z80 into half a dozen, in a generation o= r > > two. Forty thousand of them, as well as the block memory, I/O, DSP and = a > > few ARMs or PPCs to supervise the lot. > > One annoying thing is that I see a lot of families with multipliers. > why don't they simply provide adders too ? > multiplies take a lot of resources, sure, but adders are everywhere... > > > Time to dig out the old bit-slice databooks again? > > History rhymes again :-) > > Thanks for the insights, > > > - Brian > > yg > > --http://ygdes.com/http://yasep.org hm, maybe i should sell my ERA6000 ICE pod on ebay? yes that the plessey/pilkington sea of gates FPGA AnttiArticle: 137529
On Jan 21, 10:14 am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
> On 2009-01-21, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > and ironically the sample chapter supplied on that webpage is exactly
> > the chapter that I am interested in:
>
> >http://academic.csuohio.edu/chu_p/rtl/fpga_vhdl_book/fpga_vhdl_sample...
>
> I took a brief look at this and happened to notice that the author forgot
> to synchronize the rx input signal. So if you follow this example, add
> one flip-flop to avoid race conditions and another flip-flop to reduce
> the probability of metastability issues to near zero. I have emailed the
> author about this so hopefully he'll fix this. (Well, that or I just
> missed the synchronization which would be very embarrasing for me :))
>
> If you are not aware of why you need to synchronize an input signal you
> could read a longer post I wrote at the following URL:http://groups.google.se/group/comp.arch.fpga/browse_thread/thread/6b6...
>
> Or you could of course look it up in some textbook on digital design.
>
> /Andreas
yes, I remember that thread, I have to admit, I didn't quite follow
that part so well. I will be re-visiting
this shortcoming of this implementation of the RS232 but for now lets
just get our feet wet.
Here's my version of a blog on how to get this UART working. Its a
complete backup of my workspace
on the project in its natural tree form, and there is also a zip file
of the project if you want to download it in
one fail swoop (3mb) the backup is here:
http://jleslie48.com/fpga_uartjl_01/
and the zip file of that is here:
http://jleslie48.com/fpga_uartjl_01/zip090120a_fpga_uartjl_01.zip
You will also notice a notes sub-directory where these notes and
discoveries are being
documented here:
http://jleslie48.com/fpga_uartjl_01/notes/
I even used microsoft word to try and clean up the notes.txt file a
bit.
Anyway, here is the project so far, and I'd appreciate some insight as
detailed in step 6) below.
- Jon
Notes.txt:
090120
- ok so I started this project and I admit it, I'm scared and I don't
really know what I'm doing.
I have the Digilent Virtex-II development system with the ISE 10.1 and
Impact 10.1 software packages:
http://www.xilinx.com/products/devkits/XUPV2P.htm
This project started with the sources and chapter 7 of:
FPGA PROTOTYPING
BY VHDL EXAMPLES
Xilinx SpartanTM-3V ersion
Pong P. Chu
Cleveland State University
the authors website has even a download of the examples:
http://academic.csuohio.edu/chu_p/rtl/fpga_vhdl.html
and even chapter 7 as a pdf file:
http://academic.csuohio.edu/chu_p/rtl/fpga_vhdl_book/fpga_vhdl_sample_chapter.pdf
In this backup of my project,
all the examples from the book are stored in this tree as
\vhdl_examples
and all the sources I think I need are stored in \orig because
I'm sure I'll be modifying them and so I wanted to store off my
originals.
as I make milestones, I imagine new directories of backups will
emerge,
named \buxx_somethingdescriptive
as this forray will also be kept online, I will zip it up and store
it in the root
directory under zipYYMMDDx_somethingdescriptive.zip
so anyone wishing to follow in my footsteps or play along can do so.
with that said lets begin.
1) I started a new project with ISE 10.1 Project Navigator.
2) after that huba-balloo, I clicked 'add existing source' and added
all the
source I thought I needed from the examples. I had previously put
copies of
those sources in the root of the project.
I even took a screencap:
\notes\screencap01_firstsource.png
http://jleslie48.com/fpga_uartjl_01/notes/screencap01_firstsource.png
so far so good.
3) I then clicked 'synthesize -XST'. The arrows chasing each other
thingy changed after
a few seconds to a spinny type thingy and the bottom view section
started spewing
all kinds of report stuff. All well and good and I ended up with
some warnings, which
I'd like to discuss a little later. Here's the screen cap:
\notes\screencap02_firstsynth.png
http://jleslie48.com/fpga_uartjl_01/notes/screencap02_firstsynth.png
the error messages are:
Analyzing Entity <uart_test> in library <work> (Architecture <arch>).
WARNING:Xst:753 - "C:/jon/fpga_uartjl_01/uart_test.vhd" line 29:
Unconnected output port 'db_level' of component 'debounce'.
Entity <uart_test> analyzed. Unit <uart_test> generated.
Analyzing generic Entity <uart> in library <work> (Architecture
<str_arch>).
DBIT = 8
DVSR = 163
DVSR_BIT = 8
FIFO_W = 2
SB_TICK = 16
WARNING:Xst:753 - "C:/jon/fpga_uartjl_01/uart_core.vhd" line 37:
Unconnected output port 'q' of component 'mod_m_counter'.
WARNING:Xst:753 - "C:/jon/fpga_uartjl_01/uart_core.vhd" line 46:
Unconnected output port 'full' of component 'fifo'.
Entity <uart> analyzed. Unit <uart> generated.
Now I haven't used a UCF file yet, and I believe that I must, so
I'd like to discuss that in a very short time period,
but let's continue with what I have done so far.
4) I then hit the 'implement design' arrow thingy. It was very
obedient and started spinning as well. whe it was all
done it was very happy. No errors or warnings. Here's the screen
cap of that result:
\notes\screencap03_firstimplement.png
http://jleslie48.com/fpga_uartjl_01/notes/screencap03_firstimplement.png
5) checking the pinouts. well somewhere in my travels, someone
mentioned looking at the pinout report for useful stuff.
so here it is:
\notes\screencap04_firstpinoutrpt.png
http://jleslie48.com/fpga_uartjl_01/notes/screencap04_firstpinoutrpt.png
6) well now I want to take a break and review a few things, I can see
that my pinout report has some useful stuff and some
not-so useful stuff. for instance, RX and TX I think have to
somehow be associated to the DB9 that is on my board (the
root directory has a UCF file RS232.UCF in it, that I believe I
should use, and the pinouts of this "hard" uart should be
properly level shifted yes?) This example also assumed a
spartan 3 evaluation kit which I guess has a digital readout
and I think that is what those led<x> things are, so I want to get
rid of those. I also have a question about the clock
situation. the chapter describes that all the communication is to
be synched up with a clock pulse divided by 16 * something
or other (see 7.2.2) now this is all well and good, but I imagine
my system clock is different (ok, I admit it, I don't even
know where it is.) and so those calculations need to be adjusted.
So at this point I'm looking for advice and review of my work so
far. Can anybody give some insight into the issues I've
raised in 6) above?
Article: 137530I am looking for a solution to interface these standards into an FPGA (Virtex5). In an ideal world I would like a single-chip RX that supports all three standards (three inputs and one output bus to the FPGA). I am fairly certain that this can be done with a two chip solution: Multi-input DVI/HDMI RX and a DisplayPort to HDMI translator on one of those inputs. I am hoping that someone might know of a more elegant solution. Thanks, -MartinArticle: 137531
On Jan 21, 1:14=A0pm, whygee <why...@yg.yg> wrote: > Brian Drummond wrote: > > The other fine grained one was of course Xilinx's own XC6200, originall= y > > developed in Edinburgh by Algotronics (bought out by Xilinx). Much love= d > > by researchers because every detail of configuration and routing was > > made public; if there was ever a chance of a completely open-source > > toolchain, that was it. I believe the basic unit of logic was a 4-LUT > > and FF, nothing fancy. > > Oh, that is an interesting topic ! > > I have been told that today, 90% of the investments of FPGA vendors > go to SW design. Open Source is maybe a solution, since it has evolved > a lot in the last years. Though I know pretty well that current Open Sour= ce EDA > tools suck. But I would like to think in the long term. > And with all those oooold FPGA-related patents going to the public domain= , > new opportunities appear, unlike 5 or 10 years ago... > > > Consider that with current FPGAs, the area occupied by logic is dwarfed > > by the routing area. With fine grained logic that problem must be about > > an order of magnitude worse. Factor in the optimisation opportunities > > that more complex logic blocks give you; from hard-wired fast carry > > chains all the way up to multipliers or DSP units, and you can see why > > the trend is towards coarser grained logic. > > I have read that 4-LUT based ASICs with metal-layer customisation > are faster and denser, for this reason : interco transistors that > take roughly 80% of the surface are reduced a lot. > Something I have learnt only recently... Are you comparing ASICs to FGPAs? I believe that is the basis of the various ASICs available from the FPGA vendors. They just replace the programmable parts with wire. I guess in the case of LUTs that can be used like RAM, they still have to use RAM based LUTs, but they are initialized by metal rather than a bit stream. > > I would expect to see basic units like 8-bit blocks, > > almost PLD-like ? I wonder if things like the 6-LUT can be accommodated in the software by treating it as a set of 4-LUTs with very limited routing? I assume the routing details are fully table driven or something similar in the software. > > with enough > > resources that you could fit a Z80 into half a dozen, in a generation o= r > > two. Forty thousand of them, as well as the block memory, I/O, DSP and = a > > few ARMs or PPCs to supervise the lot. > > One annoying thing is that I see a lot of families with multipliers. > why don't they simply provide adders too ? > multiplies take a lot of resources, sure, but adders are everywhere... They do offer adders. Each bit uses one LUT. That seems pretty cheap to me... > > Time to dig out the old bit-slice databooks again? > > History rhymes again :-) > > Thanks for the insights, RickArticle: 137532
On Jan 21, 12:45=A0pm, whygee <why...@yg.yg> wrote: > Jonathan Bromley wrote: > > On Tue, 20 Jan 2009 21:45:05 -0800 (PST), rickman wrote: > > >> There was another company called Plus Logic but I really just can't > >> recall the structure of their devices. =A0But I'm pretty sure they > >> wern't 4 LUTs. > > I believe they had a CPLD-like structure. =A0They were absorbed > > by ??Altera after achieving some reasonable sales. > > The bottom ofhttp://www.fpga-guide.com/overview/overview.htmlsays it is X= ilinx. > > BTW, it seems that CPLD-based FPGA are not very succsessful > (and I wouldn't use them unless paid really really well). > > OTOH has anybody read about the "upcoming" memristor-based FPGA ? No, I have not read about this. But the stuff I have read about memristors indicates they are some years away from commercial application. RickArticle: 137533
On Jan 21, 8:48=A0am, FP <FPGA.unkn...@gmail.com> wrote:
> I am getting the following translate erroe in my design
>
> ERROR:NgdBuild:809 - output pad net 'clk_288' has an illegal load:
> =A0 =A0 =A0pin C on block reg1/q_0 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_1 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_2 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_3 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_4 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_5 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_6 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_7 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_8 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_9 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_10 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_11 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_12 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_13 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_14 with type FDR,
> =A0 =A0 =A0pin C on block reg1/q_15 with type FDR,
> =A0 =A0 =A0pin C on block vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/
> USER_CLK_REG
> =A0 =A0with type FDE,
> =A0 =A0 =A0pin C on block vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/
> U_SYNC_R with
> =A0 =A0type FDRE,
> =A0 =A0 =A0pin C on block vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/
> U_SYNC_F with
> =A0 =A0type FDRE,
> =A0 =A0 =A0pin C on block
> =A0 =A0vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/sync_f_edge/
> I_H2L.U_DOUT with
> =A0 =A0type FDR
>
> I am using an output DDR flip flop to create the clk_288 signal which
> further drives the CLK input of other signals.
> OFDDRRSE ddr_flop_inst(
> =A0 =A0 =A0 .Q( clk_288 ),
> =A0 =A0 =A0 .C0( adc1_dry_p ),
> =A0 =A0 =A0 .C1( adc1_dry_n ),
> =A0 =A0 =A0 .CE( 1'b1 ),
> =A0 =A0 =A0 .D0( adc1_dry_p ),
> =A0 =A0 =A0 .D1( adc1_dry_n ),
> =A0 =A0 =A0 .R( ~fpga_reset_n_temp ),
> =A0 =A0 =A0 .S( 1'b0 )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 );
>
> Please suggest a solution. Thanks in advance
First of all - NEVER hook the clock to the D input
of a flip-flop. For one thing, the clock should always
be at zero just before every rising clock edge, so assuming
zero hold time it would just cause the output to always
go low.
so assuming zero hold requirement:
OFDDRRSE ddr_flop_inst(
.Q( clk_288 ),
.C0( adc1_dry_p ),
.C1( adc1_dry_n ),
.CE( 1'b1 ),
.D0( 1'b0 ),
.D1( 1'b0 ),
.R( ~fpga_reset_n_temp ),
.S( 1'b0 )
);
would be the equivalent of what you wrote
The following is closer to what you may have meant:
OFDDRRSE ddr_flop_inst(
.Q( clk_288 ),
.C0( adc1_dry_p ),
.C1( adc1_dry_n ),
.CE( 1'b1 ),
.D0( 1'b1 ),
.D1( 1'b0 ),
.R( ~fpga_reset_n_temp ),
.S( 1'b0 )
);
Secondly, the DDR flip-flop I describe does not double
the adcl_dry_p frequency, it only matches it and delays
it by the clock to output time of the flip-flop. i.e.
on the rising edge of adcl_dry_p it goes high (value on
the D0 input) and on the rising edge of adcl_dry_n it
goes low (value on the D1 input). This sort of thing
is useful for buffering a signal already on a global
clock net. It doesn't double your clock frequency.
Article: 137534On 2009-01-22, akshay <akshayvreddy@gmail.com> wrote: > Hi, > i am trying to implement a small SIMD machine on and fpga vertex-2 chip.To > test this unit i have to load a user defined RAM with data. i have an > assembler that generates hex code. I have to get this hex code into the RAM > so that i can test the data flow. > can anybody tell how this is done or is there any other way i can populate > the RAM. > thank you You could either initialize the RAM in your VHDL/Verilog code if you have inferred it (make sure to initialize the entire RAM, otherwise I think XST will ignore all initializations) or use the data2mem utility. (Read up on it in the Xilinx documentation.) Using data2mem also means that you don't have to resynthesize the design when changing the program. Finally, the most elegant solution is probably to write a small bootloader in ROM which you can use to download your program via a serial port or so. /AndreasArticle: 137535
Antti wrote: > hm, > > maybe i should sell my > > ERA6000 ICE pod on ebay? > > yes that the plessey/pilkington sea of gates FPGA that is valuable to so few people... but pictures and a small webpage would be useful for more people :-) > Antti YG -- http://ygdes.com / http://yasep.orgArticle: 137536
rickman wrote: > On Jan 21, 1:14 pm, whygee <why...@yg.yg> wrote: >> why don't they simply provide adders too ? >> multiplies take a lot of resources, sure, but adders are everywhere... > They do offer adders. Each bit uses one LUT. That seems pretty cheap to me... I meant 16-bit or 32-bit adders. How many 4-LUTs does it take to add 32 bits _fast_ ? Not 32... > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 137537
rickman wrote: > On Jan 21, 12:45 pm, whygee <why...@yg.yg> wrote: >> OTOH has anybody read about the "upcoming" memristor-based FPGA ? > No, I have not read about this. But the stuff I have read about > memristors indicates they are some years away from commercial > application. Sure. I don't want to be too old to use them when they become available :-) Xilinx seems to use to buy things and swallow companies, maybe they'll get a hint and speed things up this way ? > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 137538
On Jan 20, 9:45=A0pm, rickman <gnu...@gmail.com> wrote: [.. snip ..] OK rickman, you've apparently been around for awhile if you can remember all these. :-) > Atmel is a forgotten FPGA vendor. =A0They still sell an FPGA with an AVR > included. =A0This is based on their second generation FPGA with a > (single) 3 input LUT, IIRC. [.. snip ..] The product line is/was called FPSLIC. http://www.atmel.com/products/FPSLIC/ IIRC, the FPSLIC fabric is based off the earlier Concurrent Logic architecture, although my feeble memory might be fooling me. > > Another forgotten vendor is Motorola, most likely because their > product was stillborn. =A0I seem to recall that it was *very* fine > grained although I can't say I ever read any details. =A0I believe they > called it "Crosspoint" or "Crossfield" or something like that. [.. snip ..] This one was called CORE+ based on Motorola's ColdFire processor. I was working a company called Triscend that was doing something similar, but with 8051 and ARM7 coupled with a coarse-grained FPGA fabric. We were worried about CORE+ due to Motorola's market presence, the feature set, and Motorola's stated low, low price. http://findarticles.com/p/articles/mi_m0EKF/is_n2206_v44/ai_20323848 The FPGA fabric was just OK. It was another incarnation of the Pilkington fine-grained architecture. Pilkington, if nothing else, were the world's best FPGA salespeople. They sold the same architecture to the likes of Toshiba, Motorola, and others that I can't now remember. > There was another company called Plus Logic but I really just can't > recall the structure of their devices. =A0But I'm pretty sure they > wern't 4 LUTs. You are correct in that Plus+Logic did not use a 4LUT. They actually became Xilinx' CPLD division during the last great industry consolodation. http://findarticles.com/p/articles/mi_m0EKF/is_n1895_v38/ai_11874375 -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 137539
On Wed, 21 Jan 2009 09:03:59 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Jan 21, 8:00 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> >> Consider that with current FPGAs, the area occupied by logic is dwarfed >> by the routing area. With fine grained logic that problem must be about >> an order of magnitude worse. >I don't think that is anything new. Back when the XC4000 was new I >was told that "We sell you the routing and give you the logic for >free". > That was the quote. I suspect it's at least equally true today and still driving the balance point. >> I would expect to see basic units like 8-bit blocks, with enough >> resources that you could fit a Z80 into half a dozen, in a generation or >> two. Forty thousand of them, as well as the block memory, I/O, DSP and a >> few ARMs or PPCs to supervise the lot. > >Personally, I would like to see larger functional units as that would >reduce the complexity of the routing fabric. But I think it would be >too much of an impact on the software to properly utilize it >effectively. I am sure this will come, but not in the next few >years. Then again, doesn't the Stradix use 6-LUTs? Maybe, I haven't really kept abreast of the Altera line. - BrianArticle: 137540
On Wed, 21 Jan 2009 19:14:12 +0100, whygee <whygee@yg.yg> wrote: > >> I would expect to see basic units like 8-bit blocks, >almost PLD-like ? Heh, I almost suggested the 22V10 as a candidate for a basic block! 40000 of them could be interesting but I don't want to dust off my CUPL manual for thah... >One annoying thing is that I see a lot of families with multipliers. >why don't they simply provide adders too ? >multiplies take a lot of resources, sure, but adders are everywhere... Essentially every LUT is already part of an adder about as fast as they can make them; I suspect an adder alone would be too small a "grain" to be worthwhile. But the mults now have an accretion of accumulators and other low level facilities around them, so maybe someone is listening to you. In the V5 there are partial adaptations towards supporting single-precision floats; full support might be another useful addition... - BrianArticle: 137541
On Wed, 21 Jan 2009 11:09:45 -0800 (PST), Antti <Antti.Lukats@googlemail.com> wrote: >On Jan 21, 8:14 pm, whygee <why...@yg.yg> wrote: >> Brian Drummond wrote: >> > The other fine grained one was of course Xilinx's own XC6200, originally >> > developed in Edinburgh by Algotronics (bought out by Xilinx). > >hm, > >maybe i should sell my > >ERA6000 ICE pod on ebay? > >yes that the plessey/pilkington sea of gates FPGA > >Antti Heh, the Plessey ERA. I was introduced to that about the end of the Rekursiv project; and it started me thinking about reconfigurable computing. Until then, I had dismissed SRAM based FPGAs as a dumb idea (like a PAL or Altera EPLD that forgets what it is when the power fails; and SLOOOW besides!) Pilkington (a glassware company!) sold it to Plessey, and Motorola, and who else? I thought the Algotronics/Xilinx was an independent development but I can't be certain... Don't sell the ICE pod ... I expect my Inmos T800 eval board is worth even more... (I never did get a Rekursiv though) - BrianArticle: 137542
On Wed, 21 Jan 2009 09:44:11 -0800 (PST), jleslie48 <jon@jonathanleslie.com> wrote: >On Jan 21, 10:53 am, "jeffrey.johnson" <j...@fpgadeveloper.com> wrote: >> You will find beginner tutorials for the XUPV2P board on the FPGA Developer >> website: >> >> http://www.fpgadeveloper.com >> >> Specifically for getting RS232 communications working, try the "Base >> System Builder" tutorial. > >Yes, I looked at that example. It uses the powerPC which I don't >believe I have access to, >my project is supposed to use the xc2vp30 only and not another >chipset, or did I just say something really stupid (ie, I don't have a >clue what the powerpc is, and is it part of the the xc2vp30?) There are 2 PowerPCs in the xc2vp30; you can use them or ignore them as you wish. If you are following an example EDK project (like that one) it will take the pain out of using them; deviate much from the example and things can get very confusing very fast. My first experience with the EDK system; I stepped off the path, simply to change the input clock from the example I was following, and it took me nearly a week to get the project to build again and communicate at the right baud rate! The block of hardware it produces (PPC, program&data memory, bus, bus master, bus slave interfaces, interrupt logic, etc, and finally a UART) will be at least a hundred times more complex than a simple RS232 UART and a state machine to feed it "hello world". (And probably no more time to generate; if you strictly follow the path) But it will run C. Your choice. But once you get used to hardware the PPC will seem painfully slow. - BrianArticle: 137543
Hi, i am trying to implement a small SIMD machine on and fpga vertex-2 chip.To test this unit i have to load a user defined RAM with data. i have an assembler that generates hex code. I have to get this hex code into the RAM so that i can test the data flow. can anybody tell how this is done or is there any other way i can populate the RAM. thank you akshayArticle: 137544
Hi Rick !
this is the rest of the discussion from comp.arch.embedded.
rickman wrote:
> Have you considered a different family? There is a $40 Xilinx eval
> board available from Avnet. But it still does not have ram. That
> will likely be a $200 or higher board.
I'm already satisfied with what I got from Actel
("it works and has what i want")
and I bet that any issue I'll have with SDRAMs
will not be related to the FPGA family itself,
but rather, come from my misunderstanding of the
SDRAM's datasheets or something stupid like that...
I have a 2nd hand Altera (NIOS) board (without support tools)
and a pair of XCV400 waiting for a suitable PCB, and I look around
for other vendors. But I don't want to be diverted/distracted from
actual development itself : either I spend my time and money
evaluating vendors, or I do something with what I already have...
Guess which one eventually brings money home :-)
> The only hard part is the wiring. A decoupling cap will need to be
> wired directly between the power and ground pins.
of course. I just got some really cool ultra-miniature high-capacity ceramic
capacitors and that's where they are suitable :-)
> Actually, this may
> be a show stopper. The low impedance of the ground plane and its
> capacitance helps a lot to reduce the high freq spikes on the power
> bus. By wiring power it is possible to add too much inductance and
> the cap may not be able to provide a low enough impedance.
adding capacity and reducing impedance is not an issue,
I can use larger diameter wires at will
and my collection of capacitors is still growing :-)
> As long as your wires are very short (both on board and off board),
> less than 2" for example, the SI and clock timing will not be
> significant issues. To mitigate the output delays on the FPGA you
> should register all signals in the IOBs.
of course. I always latch outputs.
>> Also my designs don't clock faster than 100MHz, and I thought
>> that it's possible to downclock SDRAM chips, provided the cycles
>> are adjusted.
>
> That will work. You can clock an SDRAM as slow as you want to some
> point. You do have to provide a periodic refresh cycle unless you are
> doing that in software. But the clock speed won't have much to do
> with the SI and power decoupling issues.
My fear is that my dear 475 'scope is limited to 200MHz so I could
miss things. But that will come later, when going "high speed" on PCB,
since the SDRAM initialisation dance in itself looks scary...
I'll probably have to finish my small CPU core before I go further,
since a programmed sequence will spare me the effort to design
a (scary) FSM.
<afterthought>
And if the SDRAM can be clocked as slowly as one wants,
then I could even "prototype" the SDRAM interface
with "bitbang"-like software, and then move slowly from
soft to VHDL as it starts to work...
>>> You also need an SDRAM controller inside the FPGA, parameterised to your
>>> particular SDRAM chips.
>> Sure, I'm looking at datasheets and VHDL "cores" too.
>>
>> Should this discussion continue on comp.arch.fpga ?
>
> That would be a good venue.
so here we go.
> I have not found a good venue for discussing FPGA CPU cores.
Note that the request is (was) independent of YASEP,
I've just unearthed some /old/ DSP projects that were
still out of my reach 6 months ago.
However it seems that I'll need at least a small CPU
to get the thing working (both the SDRAM and the DSP).
This encourages me to continue with YASEP :-)
> If you are interested in MISC processors,
> comp.lang.forth is a good place.
:-)
However YASEP is not MISC, it's just "small" :-)
But Forth and the likes are definitely worth caring.
>> Furthermore, I believe that since I'll have to use SDRAM anyway
>> one day, then I should hit the bullet and go forward.
> You can get the Altera softare for free just like the Xilinx software.
I'm investigating that but I don't give Altera high priority,
since they force me on Windows. Unless someone thinks that
"or else pay $2500 for your linux license" means something else.
OK I confess that I use Actel's suite under Vista (ouch)
but at least there is still the possibility to use the
Linux version (in some ... way). I'm investigating it now...
> The programming cable is not a lot of money.
I consider making my own,
once I have time and all the SW issues solved.
> I would bite
> the bullet and use that for a first pass. Wiring an SDRAM chip is
> likely to delay you some considerable time.
I have to balance several things :
- the time and cost of acquiring, installing, configuring, using, mastering
yet another vendor's tools, and getting around its specific gotchas
- the potential dangers of using a single vendor's products
- the actual usefulness, price, and reward of each particular project
(and the SDRAM is not a necessity now).
It looks like a "dirty hack" with 25mil wires from IDE cables
is the fastest, cheapest and easiest way now.
Maybe it won't work but it will probably help me
understand and get a first foot in the sh^Wmatter...
Regards,
> Rick
yg
--
http://ygdes.com / http://yasep.org
Article: 137545On Jan 21, 6:24 pm, whygee <why...@yg.yg> wrote: > rickman wrote: > > On Jan 21, 1:14 pm, whygee <why...@yg.yg> wrote: > >> why don't they simply provide adders too ? > >> multiplies take a lot of resources, sure, but adders are everywhere... > > They do offer adders. Each bit uses one LUT. That seems pretty cheap to me... > > I meant 16-bit or 32-bit adders. > How many 4-LUTs does it take to add 32 bits _fast_ ? > Not 32... I don't know just how fast a 32 bit adder from 32 LUTs will run and I don't know how fast a 32 bit hard adder will run. I do know that the long path is the carry chain and this has been highly optimized in most FPGAs. Do you know numbers? The only "fast" adder I know about is a propagate/generate design. If this is implemented using 4-LUTs I believe it will use log2(n) levels and n-1 LUTs in addition to the adder. So a 32 bit adder would use 64 LUTs (32 + 31 + 1 more to produce the final carry out if needed). I can't say much about how fast this circuit would be because the carry chain is very fast and the LUTs are rather slow. Even if you compare 6 levels of LUTs I expect 32 levels of carry will be faster. If you get to 64 bit, perhaps 7 levels of LUTs may be faster but I would not bet on it. RickArticle: 137546
"whygee" <whygee@yg.yg> wrote in message news:49776167$0$28675$7a628cd7@news.club-internet.fr... > Jonathan Bromley wrote: >> The QuickLogic architecture was > "was" ? I thought that Quicklogic still exists ... > This page shows that only 4 players remain : > Altera, Actel, Lattice & Xilinx. > It will need a good update soon since > SiliconBlue seems to be on the good tracks, > and maybe one or two other new companies > are trying to emerge. Interesting times... >>> BTW, I've also spotted M2000 >>> which is now http://www.aboundlogic.com >>> What are they really doing ? >> Ah, a Stealth Mode website. Thanks to *you* for >> the pointer! > I just called the french office (I'm french) and ... surprise ! > I spoke with an ex-co-worker :-) He expects > announcements by the end of the year and he will keep me informed. > Expect a familiar-looking 4-LUT btw, unless things really changed :-) > Now, if only they needed an Open Source Evangelist in their team, > I would sign again ;-) The other new potential player in the game is Achronix http://www.achronix.com/ with their "clockless" logic-based FPGA blocks. Their "picoPIPE(TM)" is a collection of 8 (4-?)LUTs that talk via their clockless logic protocols. They wrap that around a synchronous fabric to support EDA software (at least in theory). I have no direct experience with them; I work for BAE Systems which is trying to take this technology and make it fully radiation-hard for the space business. I just have a need for this class of FPGA for a space program several years out (fingers crossed). -MartyArticle: 137547
hi ! Marty Ryba wrote: > The other new potential player in the game is Achronix I've seen that, too. actually, only the website. > http://www.achronix.com/ with their "clockless" logic-based FPGA blocks. > Their "picoPIPE(TM)" is a collection of 8 (4-?)LUTs that talk via their > clockless logic protocols. They wrap that around a synchronous fabric to > support EDA software (at least in theory). I have no direct experience with > them; I work for BAE Systems which is trying to take this technology and > make it fully radiation-hard for the space business. I just have a need for > this class of FPGA for a space program several years out (fingers crossed). I would be very curious to see how this unfolds. I hope that it's not "yet another promising technology that fails for whatever reason like most precedent ones"... only those that succeed, or fail miserably, are remembered :-/ Concerning Achronix, there is no mention or detail concerning the design/development environment, can you tell us anything about this, the requirements, the tools, etc. ? thanks for sharing your experiences, > -Marty yg -- http://ygdes.com / http://yasep.orgArticle: 137548
Hi :-) rickman wrote: > On Jan 21, 6:24 pm, whygee <why...@yg.yg> wrote: >> rickman wrote: >>> They do offer adders. Each bit uses one LUT. That seems pretty cheap to me... >> I meant 16-bit or 32-bit adders. >> How many 4-LUTs does it take to add 32 bits _fast_ ? >> Not 32... > > I don't know just how fast a 32 bit adder from 32 LUTs will run and I > don't know how fast a 32 bit hard adder will run. I do know that the > long path is the carry chain and this has been highly optimized in > most FPGAs. Do you know numbers? I don't, and the fact that Actel uses a completely different system does not help me. I have struggled to get a decently fast 32-bit add/sub unit on A3P. There is no "fast carry chain" so the price in logic "tiles" is quite high. This makes me regret that no dedicated addition "blocks" are included. Along with some SRAM and glue (latch/registers and Muxes), addition is certainly the function that I use most. I'm interested to read and compare numbers from different FPGA families for 8, 16 and 32-bit wide adders (latency, area cost etc.). Regards, > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 137549
On Jan 21, 9:15 pm, whygee <why...@yg.yg> wrote:
> Hi Rick !
>
> this is the rest of the discussion from comp.arch.embedded.
>
> rickman wrote:
> > Have you considered a different family? There is a $40 Xilinx eval
> > board available from Avnet. But it still does not have ram. That
> > will likely be a $200 or higher board.
>
> I'm already satisfied with what I got from Actel
> ("it works and has what i want")
> and I bet that any issue I'll have with SDRAMs
> will not be related to the FPGA family itself,
> but rather, come from my misunderstanding of the
> SDRAM's datasheets or something stupid like that...
>
> I have a 2nd hand Altera (NIOS) board (without support tools)
> and a pair of XCV400 waiting for a suitable PCB, and I look around
> for other vendors. But I don't want to be diverted/distracted from
> actual development itself : either I spend my time and money
> evaluating vendors, or I do something with what I already have...
> Guess which one eventually brings money home :-)
I am of the opinion that with the top three FPGA vendors, Xilinx,
Altera and Lattice, there is not a lot to "evaluate". Each vendor has
at least one high end line that is fast, dense and has lots of bells
and whistles. They also have at least one line of economy chips that
are cheap and yet still very capable. Unless you are planning to push
the limitations of any of these chips, what is there to evaluate? I
didn't get the impression that this is about a product, so if you are
just using this as a learning tool, what basis do you have for
evaluation? What is your criteria? I know that I would choose the
device that is easiest to prototype with and later worry about that
device I want to use in a product.
BTW, when you say you have no support tools for the Altera device, I
think i told you that the Altera FPGA tools are available free.
> > The only hard part is the wiring. A decoupling cap will need to be
> > wired directly between the power and ground pins.
>
> of course. I just got some really cool ultra-miniature high-capacity ceramic
> capacitors and that's where they are suitable :-)
>
> > Actually, this may
> > be a show stopper. The low impedance of the ground plane and its
> > capacitance helps a lot to reduce the high freq spikes on the power
> > bus. By wiring power it is possible to add too much inductance and
> > the cap may not be able to provide a low enough impedance.
>
> adding capacity and reducing impedance is not an issue,
> I can use larger diameter wires at will
> and my collection of capacitors is still growing :-)
The wire diameter has very little to do with the impedance. Any
capacitor you use has impedance. You can see this very clearly if you
look at the impedance-frequency curves for the parts. The resonant
frequency tells you the frequency at which the capacitive and
inductive impedance are equal. As the frequency continues to increase
the impedance rises. For a high speed design the impedance of the cap
becomes significant at frequencies that are important. That is why
power planes are used. They provide a low impedance at frequencies
into the GHz range.
Then there is ground bounce. Your wiring will just add to that
problem.
> > As long as your wires are very short (both on board and off board),
> > less than 2" for example, the SI and clock timing will not be
> > significant issues. To mitigate the output delays on the FPGA you
> > should register all signals in the IOBs.
>
> of course. I always latch outputs.
>
> >> Also my designs don't clock faster than 100MHz, and I thought
> >> that it's possible to downclock SDRAM chips, provided the cycles
> >> are adjusted.
>
> > That will work. You can clock an SDRAM as slow as you want to some
> > point. You do have to provide a periodic refresh cycle unless you are
> > doing that in software. But the clock speed won't have much to do
> > with the SI and power decoupling issues.
>
> My fear is that my dear 475 'scope is limited to 200MHz so I could
> miss things. But that will come later, when going "high speed" on PCB,
> since the SDRAM initialisation dance in itself looks scary...
> I'll probably have to finish my small CPU core before I go further,
> since a programmed sequence will spare me the effort to design
> a (scary) FSM.
>
> <afterthought>
>
> And if the SDRAM can be clocked as slowly as one wants,
> then I could even "prototype" the SDRAM interface
> with "bitbang"-like software, and then move slowly from
> soft to VHDL as it starts to work...
That will be interesting. There are limits to how slow it can run,
check the data sheet. The initialization is not all that bad, at
least if you are using SDRAM. I did one of those some 10 years ago.
I just made a FSM and it worked the first time. I did find a lot of
good app notes and data sheets at Micron Semi. I don't know if they
are still available. I have them in print form. 8^*
> >>> You also need an SDRAM controller inside the FPGA, parameterised to your
> >>> particular SDRAM chips.
> >> Sure, I'm looking at datasheets and VHDL "cores" too.
>
> >> Should this discussion continue on comp.arch.fpga ?
>
> > That would be a good venue.
>
> so here we go.
You can also cross post to both groups.
> > I have not found a good venue for discussing FPGA CPU cores.
>
> Note that the request is (was) independent of YASEP,
> I've just unearthed some /old/ DSP projects that were
> still out of my reach 6 months ago.
> However it seems that I'll need at least a small CPU
> to get the thing working (both the SDRAM and the DSP).
> This encourages me to continue with YASEP :-)
>
> > If you are interested in MISC processors,
> > comp.lang.forth is a good place.
>
> :-)
> However YASEP is not MISC, it's just "small" :-)
> But Forth and the likes are definitely worth caring.
YASEP... Yet Another Small Embedded Processor? I feel the same way
about mine. I designed a CPU some 8 years ago based on the Forth
model. It turned out remarkably similar to Bernd Paysan's b16, but
with very different instruction format. From the work I have done, it
appears that the data path will dominate the size of the design. Then
the efficiency is determined by how well your instruction set uses
parallelism in the data path. There is another project called the ZPU
that is trying to design a processor that can be implemented in as
small a footprint as possible and also be capable of implemented as a
high speed version while being binary compatible. It is also stack
based, but supported with a C compiler.
There is a lot to learn by working with someone else's design. I
guess I am saying you can learn a lot more from someone else than you
can by yourself.
> >> Furthermore, I believe that since I'll have to use SDRAM anyway
> >> one day, then I should hit the bullet and go forward.
> > You can get the Altera softare for free just like the Xilinx software.
>
> I'm investigating that but I don't give Altera high priority,
> since they force me on Windows. Unless someone thinks that
> "or else pay $2500 for your linux license" means something else.
>
> OK I confess that I use Actel's suite under Vista (ouch)
> but at least there is still the possibility to use the
> Linux version (in some ... way). I'm investigating it now...
>
> > The programming cable is not a lot of money.
>
> I consider making my own,
> once I have time and all the SW issues solved.
I'll let this whole can of worms alone. There is another thread about
using Windows or more specifically, Vista. It is getting long winded
and the more radical elements are coming out.
> > I would bite
> > the bullet and use that for a first pass. Wiring an SDRAM chip is
> > likely to delay you some considerable time.
>
> I have to balance several things :
> - the time and cost of acquiring, installing, configuring, using, mastering
> yet another vendor's tools, and getting around its specific gotchas
> - the potential dangers of using a single vendor's products
> - the actual usefulness, price, and reward of each particular project
> (and the SDRAM is not a necessity now).
>
> It looks like a "dirty hack" with 25mil wires from IDE cables
> is the fastest, cheapest and easiest way now.
> Maybe it won't work but it will probably help me
> understand and get a first foot in the sh^Wmatter...
Man, you *are* a masochist! Good luck.
>
> --http://ygdes.com/http://yasep.org
I took a look. I'm just curious, why are you designing your own
processor? I assume you are aware that there are literally dozens of
other processors out there... hence the name.
Rick
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