Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I'll have a look at this one. John Adair Enterpoint Ltd. On 10 Aug, 21:03, "Pete Fraser" <pfra...@covad.net> wrote: > "John Adair" <g...@enterpoint.co.uk> wrote in message > > news:d4baa37f-f871-4143-9711-23ce3d444009@g1g2000vbr.googlegroups.com... > > > Your chance to have input to what we bring to market as Spartan-6 > > products. > > I do a lot of video algorithm development. > DVI (dual-link) I/O would be great. > HDMI and DisplayPort would be a nice addition. > > PeteArticle: 142426
On 10 Aug., 14:38, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > it seems that i may have lost all my skills of using google :( > as I havent found any ready to use HDL for for DS DAC > with higher order than 1 > > only research papers, or then commercial cores, but absolutly > no HDL sources. this cant be true? > > or is there some magic reason why all online DS DAC code > is first order only? so far i have failed to figure out what the > reason could be. > > Antti It's been a long time since I last worked with DSMs, second order is simple enough that might be why you can't find any? third order and higher get a bit more tricky to implement because you can't just add more stages and keep it stable so you need a different structure even second order is potentially unstable, afair usually with close to fullscale inputs -LasseArticle: 142427
John Adair <g1@enterpoint.co.uk> wrote: > Yes if you can hit a combination that suits a particular school you > could make it worth doing. That's only every really happened though > with a couple of boards in the market as far as I know. If you look at > the sales of Spartan-3 boards apart from those boards the sales are > relatively low and not in the critical mass area to make that all > work. However if you have particular suggestions I am open to looking > at them and pricing the cost of adding them to a product. I have no current connection to a school CS/EE department. I do remember doing TTL based projects in CS/EE lab courses, but I understand that they don't do that anymore, but use simulation instead. At FCCM95 I was part of a discussion that FPGA companies should offer free software to help people get started in FPGA work, especially for introductory CS/EE classes. In years past, the computer industry bought enough TTL chips to keep quantities up and prices low. It seems that many are still available for low prices, but maybe not so much longer. I am not sure what you would need to do to get a school to start using a board, but I believe it would be better than learning only through simulation. -- glenArticle: 142428
Hi,all I'm not a FPGA engineer or IC designer. In fact, I'm a DSP engineer. So I have little knowledge about FPGA and IC design. I am wandering the way that a algorithm is implemented in IC. In IC desgin, the first step is algorithm design and C model implementation. Do algorithm engineers need to know FPGA implementation details In this step? If they have no idea about FPGA implementation, the algorithm may not be implemented efficiently in FPGA. When algorithm engineers know FPGA well they choose the efficent methods which can minimize area and power consumption. If FPGA engineers know little about algorithms, they can't make trade off between algorithm complexity and implementation efficiency. There is a gap between algorithm design and FPGA implementation. In IC industry, how is this problem solved? Best Regards JoggingArticle: 142429
> There is a gap between algorithm design and FPGA implementation. > In IC industry, how is this problem solved? You're not much of an "algorithm engineer" if you don't know how something will be implemented. JonArticle: 142430
glen herrmannsfeldt wrote: > John Adair <g1@enterpoint.co.uk> wrote: > > Yes if you can hit a combination that suits a particular school you > > could make it worth doing. That's only every really happened though > > with a couple of boards in the market as far as I know. If you look at > > the sales of Spartan-3 boards apart from those boards the sales are > > relatively low and not in the critical mass area to make that all > > work. However if you have particular suggestions I am open to looking > > at them and pricing the cost of adding them to a product. > I am not sure what you would need to do to get a school to > start using a board, but I believe it would be better than > learning only through simulation. We use the DARNAW1 board in a beginners course (implementation of a 16 bit minimal processor in a total time of about 12 hours). But you don't need a board for every student but only one for the class (downloading the bit file is just the final test). http://www.bitlib.de/pub/mproz/mproz2a.pdf http://www.bitlib.de/pub/mproz/mproz3_e.pdf But the current Xilinx software is not in a state (no back annotation of the simulation results into the schematics) that we can use it for more than a trivial design (we use schematics entry, no VHDL). Therefore we still have to use the old DOS Viewlogic/Xilinx software and a XC3195 FPGA for the design of a more powerful 16 bit CPU in a later laboratory course. http://www.bitlib.de/pub/xproz/Article: 142431
On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote: > In IC desgin, the first step is algorithm > design and C model implementation. I always wondered why anyone would want to model the algorithms in C nowadays. There are so many nice modern languages around with object orientation, etc. Prototyping should be much quicker and less error prone with any of these compared to C. > Do algorithm > engineers need to know FPGA implementation details > In this step? I think it is sufficient to have some information on the cost of various operations, like the number and size of RAMs, Multipliers, FIFOs etc. And some informations on the relativ speed of these operations. Kolja SulimmaArticle: 142432
Hi,
If anyone can shed some clues on our dilemma with using odd starting
addresses with our DDR2 controller, please write.
We have been using a MIG 1.6-generated DDR2 controller successfully
for a couple of years until we recently started using "odd" starting
addresses. By "odd" we are referring to those addresses that aren't
bound by the burst length. For example, we are using a burst length of
4. So we have no problems whenever we start off with the two LSB's of
the address as "00." But if those two LSB's are 1, 2, or 3. It doesn't
work.
We were advised that during write bursts, the DDR2 controller ignores
the two LSB's, so we have to use masking for write bursts and align
the data properly. For read bursts, we were told that the controller
does NOT ignore the LSB's, that we can use the explicit address.
So, to perform a burst of 32-bit data {1,2,3,4} into memory starting
at address 1, we would do the following sequence (our data bus size is
64 bits):
CYCLE 1
DATA = X on upper 32 bits, 1 on lower 32 bits (X=don't care)
MASK = 0xF0 (Mask upper 32 bits)
ADDR = 0x1
assert addr and data strobes
CYCLE 2
DATA = 2, 3
MASK = 0x00 (no mask)
ADDR = X
assert data strobe
CYCLE 3
DATA = 4, X
MASK = 0x0F (mask lower 32 bits)
ADDR = 0x5 (increment initial addr by 4)
assert addr and data strobe
CYCLE 4
DATA = X, X
MASK = 0xFF (mask all data bits)
ADDR = X
assert data strobe
Do you agree with the above sequence? If not, I'd like to hear what
has worked for you.
Thank you for any clues.
John
Article: 142433Herbert I hadn't seen these labs before but it's good to see that you are doing exactly what we expected of Darnaw1 - low tech carrier boards with the Darnaw1 on top with the FPGA and memory features. Did you hand etch the PCB as well? The Darnaw1 is getting a mid-life update with slightly bigger SPI Flash coming later this year but we will be continuing the range with Darnaw2 as well. For those in the know this was originally scheduled to be V4-FX12 based product but as we slipped on getting this one out it is almost certainly going morph into a Spartan-6 product with similar features to Darnaw1. It should be pin compatible(PGA pin usage) as well. That is one my main criteria to the team on this product. It will have probably a DDR3 dram instead of the SDRAM on Darnaw1 but otherwise just bigger and faster resources. There other easy to use parts coming as well. The Craignell2 family may expand with a larger pincount version assuming we don't have Spartan-6 based Craignell3 there before it. Craignell3 will fill the gaps better the Darnaw products and existing Craignell products. Developing our monster board - Merrick1 has been slowing down the releases of a pile of new products. Now that is out in the wild the team working hard to bring those releases to the market and we should have a lot of new things Q3/4 this year for all of you. John Adair Enterpoint Ltd. On 11 Aug, 13:19, Herbert Kleebauer <k...@unibwm.de> wrote: > glen herrmannsfeldt wrote: > > John Adair <g...@enterpoint.co.uk> wrote: > > > Yes if you can hit a combination that suits a particular school you > > > could make it worth doing. That's only every really happened though > > > with a couple of boards in the market as far as I know. If you look at > > > the sales of Spartan-3 boards apart from those boards the sales are > > > relatively low and not in the critical mass area to make that all > > > work. However if you have particular suggestions I am open to looking > > > at them and pricing the cost of adding them to a product. > > I am not sure what you would need to do to get a school to > > start using a board, but I believe it would be better than > > learning only through simulation. > > We use the DARNAW1 board in a beginners course (implementation > of a 16 bit minimal processor in a total time of about 12 hours). > But you don't need a board for every student but only one for > the class (downloading the bit file is just the final test). > > http://www.bitlib.de/pub/mproz/mproz2a.pdfhttp://www.bitlib.de/pub/mproz/mproz3_e.pdf > > But the current Xilinx software is not in a state (no back annotation > of the simulation results into the schematics) that we can use it > for more than a trivial design (we use schematics entry, no VHDL). > Therefore we still have to use the old DOS Viewlogic/Xilinx software > and a XC3195 FPGA for the design of a more powerful 16 bit CPU in > a later laboratory course. > > http://www.bitlib.de/pub/xproz/Article: 142434
For a DDR2 memory using a seq burst type the order of the burst will depend on the lower bits of the column addr. Addr LSB = 00 Burst = 0,1,2,3 Addr LSB = 01 Burst = 1,2,3,0 Addr LSB = 10 Burst = 2,3,0,1 Addr LSB = 11 Burst = 3,0,1,2 So if you are starting from an addr with LSB that are not 00 the burst will wrap around so you will need to use a mask. I wouldn't of thought the MIG controller will do anything clever to apply the mask for you. JonArticle: 142435
On Aug 11, 11:38=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > For a DDR2 memory using a seq burst type the order of the burst will depe= nd > on the lower bits of the column addr. > > Addr LSB =3D 00 Burst =3D 0,1,2,3 > Addr LSB =3D 01 Burst =3D 1,2,3,0 > Addr LSB =3D 10 Burst =3D 2,3,0,1 > Addr LSB =3D 11 Burst =3D 3,0,1,2 > > So if you are starting from an addr with LSB that are not 00 the burst > will wrap around so you will need to use a mask. I wouldn't of thought th= e > MIG controller will do anything clever to apply the mask for you. > > Jon Thanks for responding, Jon. So is your interpretation that the DDR2 control does look at the LSB's? In which case this would make the write burst I described incompatible because I am using an address of 0x5 instead of 0x4. I would told the LSB's would be don't care in the start address during write bursts.Article: 142436
John Adair <g1@enterpoint.co.uk> wrote: ... > There other easy to use parts coming as well. The Craignell2 family > may expand with a larger pincount version assuming we don't have > Spartan-6 based Craignell3 there before it. Craignell3 will fill the > gaps better the Darnaw products and existing Craignell products. +1 vote here for Spartan-6 based Craignell3 with a large DDR2 / DDR3 in say 80 pin version but still pluggable into 40 DIL sockets for legacy applications... MarkoArticle: 142437
On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote: > Guys and Girls > > Your chance to have input to what we bring to market as Spartan-6 > products. > > We have several release candidates nearly ready now but we can still > add or modify features and I am interested in features you would all > like to have in these boards either based on things we hve done before > in our product range or even new features you would like to see. > > So go ahead and let us know what you want. I am sure a lot of audio types would like a daughter card with reasonable I2S-connected ADC and DAC devices. -aArticle: 142438
Herbert Kleebauer <klee@unibwm.de> wrote: < glen herrmannsfeldt wrote: <> I am not sure what you would need to do to get a school to <> start using a board, but I believe it would be better than <> learning only through simulation. < We use the DARNAW1 board in a beginners course (implementation < of a 16 bit minimal processor in a total time of about 12 hours). < But you don't need a board for every student but only one for < the class (downloading the bit file is just the final test). The frosh classes that I had consisted of a one term lecture class followed by a one term lab. That was 30 years ago, so things might have changed over time. Even so, the lecture class followed (in the subsequent term) by a lab seems to work well. The lecture demonstrations were done with TTL chips on little boards with bannana jacks, allowing convenient wiring during the lecture. Sometimes a logic block would be constructed during one lecture, and in the next it would be replaced by a single PC board doing the same function. I believe that even now, seeing TTL logic blocks connected together is a good way to begin to learn logic design. For the lab classes, we built circuits with TTL and solderless breadboards, but that was 30 years ago. Even so, I don't believe that one FPGA board for a whole lab class is right. Each lab station (which may be a few students) should have its own board for that group to play with. Those don't need to be owned by the student. The board that I was suggesting could also work there, but the suggestion was for a board that the student would own. To build a project and take it home. The price has to be low enough for a student to afford, but the board has to be good enough for some real projects. -- glenArticle: 142439
On Aug 11, 1:47=A0pm, Andy Peters <goo...@latke.net> wrote: > On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > Guys and Girls > > > Your chance to have input to what we bring to market as Spartan-6 > > products. > > > We have several release candidates nearly ready now but we can still > > add or modify features and I am interested in features you would all > > like to have in these boards either based on things we hve done before > > in our product range or even new features you would like to see. > > > So go ahead and let us know what you want. > > I am sure a lot of audio types would like a daughter card with > reasonable I2S-connected ADC and DAC devices. > > -a Not to rain on John's parade, but Digilent, Inc. sells inexpensive FPGA boards, plus (I believe) ADC and DAC add on modules. I don't know if they use the latest Xilinx chips or not. I've been happy with the Spartan-3 & 3E boards that I've bought from them. -Dave PollumArticle: 142440
jogging <joggingsong@gmail.com> wrote: < I'm not a FPGA engineer or IC designer. < In fact, I'm a DSP engineer. So I have little < knowledge about FPGA and IC design. I am < wandering the way that a algorithm is implemented < in IC. In IC desgin, the first step is algorithm < design and C model implementation. Do algorithm < engineers need to know FPGA implementation details < In this step? I don't believe that they necessarily need FPGA implementation details, but they do need to think in terms of logic design. Some people believe that FPGA implementations are software because they can be done in high-level languages like verilog, or even C. I disagree. You have to be able to think in terms of digital logic. If you can do that, for example as TTL gates, then I believe that you can do algorithm design for FPGAs. It IS significantly different from DSP (software) design. Once the algorithm has been designed, such as in the form of a systolic array, then someone else can do the actual coding and optimizing for the specific FPGA. -- glenArticle: 142441
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>Herbert Kleebauer <klee@unibwm.de> wrote:
>< glen herrmannsfeldt wrote:
>
><> I am not sure what you would need to do to get a school to
><> start using a board, but I believe it would be better than
><> learning only through simulation.
>
>< We use the DARNAW1 board in a beginners course (implementation
>< of a 16 bit minimal processor in a total time of about 12 hours).
>< But you don't need a board for every student but only one for
>< the class (downloading the bit file is just the final test).
>
>The frosh classes that I had consisted of a one term lecture class
>followed by a one term lab. That was 30 years ago, so things might
>have changed over time. Even so, the lecture class followed
>(in the subsequent term) by a lab seems to work well.
30 years ago... All that is replaced with a course in Java programming
by now. IIRC we had to do a very boring I/O board for an ancient VME
system and program a driver for it in 68000 assembly but that is
already 12 years ago.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142442On Tue, 11 Aug 2009 06:24:40 -0700 (PDT), Kolja <ksulimma@googlemail.com> wrote: >On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote: >> In IC desgin, the first step is algorithm >> design and C model implementation. >I always wondered why anyone would want to model the algorithms in >C nowadays. There are so many nice modern languages around with >object orientation, etc. >Prototyping should be much quicker and less error prone with any of >these compared to C. Maybe it's because there are a lot of behavioral synthesis products for C which actually work (or at least much more promising these days (albeit very expensive)). -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 142443
On Tue, 11 Aug 2009 02:01:39 -0700 (PDT), jogging <joggingsong@gmail.com> wrote: >Hi,all > I'm not a FPGA engineer or IC designer. >In fact, I'm a DSP engineer. So I have little >knowledge about FPGA and IC design. I am >wandering the way that a algorithm is implemented >in IC. In IC desgin, the first step is algorithm >design and C model implementation. Do algorithm >engineers need to know FPGA implementation details >In this step? If they have no idea about FPGA >implementation, the algorithm may not be implemented >efficiently in FPGA. When algorithm engineers know FPGA >well they choose the efficent methods which can >minimize area and power consumption. If FPGA engineers >know little about algorithms, they can't make trade off >between algorithm complexity and implementation efficiency. >There is a gap between algorithm design and FPGA implementation. >In IC industry, how is this problem solved? While converting an algorithm implemented in C (with an underlying OS) there are 3 main issues: 1) partitioning (which parts of the implementation goes lower to hardware implementation and which parts stay at processor level) 2) Scheduling 3) dynamic range (or floating point vs fixed point). Assuming partitioning is done early & correctly, the main issues of ASIC/FPGA implementation are scheduling and dynamic range both of which relate to hardware resource use. Scheduling requires decisions on how much logic is needed in "one cycle" and is an optimization for latency, hardware resource use and timing. Dynamic range is mostly for hardware resource and timing (FP is big & slow). So when doing algorithm development you need to pay attention to how complicated the logic is in one cycle of a loop(s) and whether you are using floating point numbers or whether you can implement all your logic with integers. There are several tools which convert C to Verilog RTL these days and you can see the results relatively quickly to make changes to original C design. But nothing beats experience of someone who codes in C and finally ports to Verilog to be able to tell how easy the conversion will be. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 142444
Muzaffer Kal <kal@dspia.com> wrote: < Maybe it's because there are a lot of behavioral synthesis products < for C which actually work (or at least much more promising these days < (albeit very expensive)). What do you mean by 'work'? If there is software that can convert a serial dynamic programming implementation into a systolic array in an FPGA I will be really really surprised. To me, the advantage to using C would be the ability to use existing code, but serial code ports very poorly to hardware. In addition, it allows people to believe that they can do logic design without thinking about logic. Actually, I don't even code (for the most part) behavioral verilog. (FFs can only be done in behavioral form, but I put them in a separate module, anyway.) -- glenArticle: 142445
On Tue, 11 Aug 2009 19:43:29 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Muzaffer Kal <kal@dspia.com> wrote: > >< Maybe it's because there are a lot of behavioral synthesis products >< for C which actually work (or at least much more promising these days >< (albeit very expensive)). > >What do you mean by 'work'? > Check out the following products and decide for yourself: Mentor Catapult C Celoxica Handel C Forte CSynthesizer Synfora PICO >If there is software that can convert a serial dynamic programming >implementation into a systolic array in an FPGA I will be really really >surprised. > Get ready to be surprised (to some degree). >To me, the advantage to using C would be the ability to >use existing code, but serial code ports very poorly to hardware. >In addition, it allows people to believe that they can do logic >design without thinking about logic. Nothing wrong with that as long as it increases productivity and generates acceptable products. People had the same complaints about C vs assembly, schematics vs Verilog/VHDL and even probably grunts vs speech. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 142446
I'm not sure yet wether we will go down to the 40 pin with Craignell3. We already have both Craignell1 and Craignell2 serving this size. Craignell2 is a very good design. We put a lot of knowledge gained from Craignell1 and we can go a 512Mbit SDRAM as an option for memory and already have a 128Mbit Flash on there. All the Craignell3 would bring is a little bigger memory and maybe some more logic. It would be viable but we would need to find some market reason. However I won't rule it out as a possibility. We have some interesting concept ideas that we have as yet not talked about for the Craignell families. One of those ideas is a possible good reason to do a 40 pin Craignell3 and maybe even smaller pinouts. Doing an oversize cut down we actually done that with the existing parts for selected customer requirements so in practise it can be done. John Adair Enterpoint Ltd. On 11 Aug, 18:12, Marko Zec <z...@fer.hr> wrote: > John Adair <g...@enterpoint.co.uk> wrote: > > ... > > > There other easy to use parts coming as well. The Craignell2 family > > may expand with a larger pincount version assuming we don't have > > Spartan-6 based Craignell3 there before it. Craignell3 will fill the > > gaps better the Darnaw products and existing Craignell products. > > +1 vote here for Spartan-6 based Craignell3 with a large DDR2 / DDR3 > in say 80 pin version but still pluggable into 40 DIL sockets for > legacy applications... > > MarkoArticle: 142447
I'll have a look at what our current stuff does cover in this area but's low cost to add to a board and that could be done without budget breaking. John Adair Enterpoint Ltd. On 11 Aug, 18:47, Andy Peters <goo...@latke.net> wrote: > On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > Guys and Girls > > > Your chance to have input to what we bring to market as Spartan-6 > > products. > > > We have several release candidates nearly ready now but we can still > > add or modify features and I am interested in features you would all > > like to have in these boards either based on things we hve done before > > in our product range or even new features you would like to see. > > > So go ahead and let us know what you want. > > I am sure a lot of audio types would like a daughter card with > reasonable I2S-connected ADC and DAC devices. > > -aArticle: 142448
And indeed many people buy their boards. They are reasonable products but if you want to go further to a real product I don't think they are interested in that. That's one of the big differences with us as a commercial company and commercial targets and aims. Spartan-3 products will remain suitable targets for many people for some time to come and I expect we probably still be building Spartan-3 boards still in 5 to 10 years time even if we are doing Spartan-10 by then too. I could talk also about their designs and make comments how we are better and a pile of other things like that but that's not the point of this post. I'm also not into negative posting as such and anyway they are just one of many compeditors I need to not worry about. This also should only be a postive post to get feedback on how Enterpoint makes better products for the market. Our products already do the talking for us in many cases but I'm not complacent that we can't improve or do it better. Not every development board will suit every customer but there is a trick to providing a solution that's useful in some way. John Adair Enterpoint Ltd. On 11 Aug, 19:22, Dave Pollum <vze24...@verizon.net> wrote: > On Aug 11, 1:47=A0pm, Andy Peters <goo...@latke.net> wrote: > > > > > On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > > Guys and Girls > > > > Your chance to have input to what we bring to market as Spartan-6 > > > products. > > > > We have several release candidates nearly ready now but we can still > > > add or modify features and I am interested in features you would all > > > like to have in these boards either based on things we hve done befor= e > > > in our product range or even new features you would like to see. > > > > So go ahead and let us know what you want. > > > I am sure a lot of audio types would like a daughter card with > > reasonable I2S-connected ADC and DAC devices. > > > -a > > Not to rain on John's parade, but Digilent, Inc. sells inexpensive > FPGA boards, plus (I believe) ADC and DAC add on modules. =A0I don't > know if they use the latest Xilinx chips or not. =A0I've been happy with > the Spartan-3 & 3E boards that I've bought from them. > -Dave PollumArticle: 142449
I have a design1 that uses OSERDES and ISERDES prmitives to serialize and de-seriliaze the data at the I/O. This design1 seems to be working fine but we need to use it test some other design - design2. So we would like to connect the design1 to design2 inside the virtex4 FPGA and test it in the real hardware. There is some justification to do this so for now please go along with it. As it is OSERDES and ISERDES primitives are for the I/O pins to communicate to the outside world at higher speed. But in my application i need to use that serial interface in the Virtex4 fabric itself to test the design2. I am under the impression that using ISERDES and OSERDES in this manner is not possible. Is that correct? I can create my own serializer and de-serilizer that can work in the fabric but I am not sure if there is a better way to do this. Thanks. CP
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