Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I think what Kolja is suggesting is to use the ISERDES at the input front end of the data, and then double the width in the fabric. Sounds like a good idea for you. > So these are 6-bit nibbles at 70MHz. Should be easy with the ISERDES. > > Kolja SulimmaArticle: 91051
There are many ways to implement this, at your extremely low rate even more than many. But if the present state needs to be stored, you need 256 storage elements on-chip, and that makes a CPLD rather expensive. The smallest FPGA does this job hands down. Your job is expensive in a CPLD, trivial in any FPGA. If you only want to make one demonstrator, buy an FPGA eval board, and finish the job in no time. Peter AlfkeArticle: 91052
Waage wrote: > Antti, > > Thanks for all your input. > > I have done as you suspected, and I have downloaded an evaluation > version of ChipScope. > And now I have one more datapoint. ChipScopePro can not find the JTAG > chain, but it can > find the USB box. It reports that a connection has been made to > Platform USB and then reports... > > ERROR: Failed detecting JTAG chain. > > So, at least at this point I am VERY suspecious a communication issue > from USB to JTAG. > Does anyone know if there's some way to snoop the communication inside > the Platform Cable? Avnet do seem to be basically useless. The problems I had with the last Avnet board were that, due to use of engineering sample silicon for the Flash to program the Xilinx, the download cable MUST NOT be plugged in at power-up; basically the power ramp to the flash is slowed down too much so the flash breaks the jtag chain. So, try powering the board up without the cable plugged in, then plug the cable in to the LX board. I hope this fixes your problem, coz I am about to try to start downloading to my LX60 board any minute now.Article: 91053
Antti Lukats wrote: >>>hum, where did you find this? >>>i am also looking at STW22000 news all the time, but its seems kinda >>>vaporware or at least not obtainable ? >>> >>>antti >> >>Antti, >> Here is the link >>http://www.st.com/stonline/press/news/year2005/p1711p.htm >> >>ST seem to have two branches of ARM+FPGA, this one they call SPEAr, >>and they claim samples now, Eval PCBs in Dec.... >>Price of $12/Volume, 200K FPGA, ADC, 3 x HS-USB(!), Ethernet, >>SDRAM and I think SPI-SerialFlash boot ? >> >>-jg >> > > read carefully - the SPEAr is customized eAsic. > the fabric is e-beam programmed. Well, seems you are right, but one needs to go three layers down. The marketdroid that wrote the link above, decided eBEAM might scare off some customers, so better to use words like "configurable logic" & "unprecedented flexibility and time to market". You have to go deeper into the lower pages, and voila, words like NRE and eBEAM start to appear. Next questions most customers will ask, is what exaclty is 'low NRE', and what volumes does this approach really kick-in at ? -jgArticle: 91054
Bob wrote: >How much does it cost to produce an ASIC? This is for a >simple customized 8-bit CPU and 64KB of on-chip RAM. > > If you can do your own design, it can be a lot cheaper than the figures in some of your replies. We are doing a very tough mixed signal chip with MOSIS, and the base price for the process we are using is about $6000. I'm guessing that you might be able to cram that logic into the minimum chip size (about 16 mm ^2, I think.) Our chip is about 7 x 7 mm, and runs more than the minimum. The tough stuff is the design and mask costs, once they are right, the chips are cheap. >If it is already working in an FPGA, can I count on the >ASIC also working? > > If you roll your own, then success depends on how good and careful you are. > > JonArticle: 91055
Emtech wrote: > Hi David > Th > is is for an RGB LED demo display application. > > 1. There will be mixing of colours done at say 3ms intervals for each colour > to stay ithin the 10ms and take avantage of persistance of vision. > 2. Bits accuracy in the duty cycle is not very important since the PWM is > only for brightness control. > 3. The outputs must at least be synchronized to the colour mixing intervals, > i.e. 3ms intervals. In other words, the PWM will further divide the 3ms > intervals to control brightness. > 4. These will only be used in an RGB LED display application hence the only > real importance is the 10ms refresh limit. > > Thank you for your input. > Peter. That speed is low enough to allow any nimble 8 bit-uC to do the task. eg SiLabs have many to choose from, forthe 80C51 each PWM operation is 2 lines of assembler (or 2+1/8 lines of assembler, if you want better time alignment). Then you can add things like gamma correction, and colour skew correction, and even LED calibration in Flash.... -jgArticle: 91056
On Thu, 27 Oct 2005 20:25:19 +0200, "Antti Lukats" <antti@openchip.org> wrote:
>NEWS: LeopardLogic has ceased operations. It wasnt directly FPGA but rather
>asic with part of it as configurable fpga fabric.
>
>Cypress is also out of PLD business silently, well that was to be expected.
>
>humm, who is next?
>
>antti
The death of Leopard Logic is in line with my estimates on seeing their
"product" presentation 2 or 3 years ago. It was impossible to tell whether
they were selling
1) FPGAs
2) FPGA IP (as in FPGA fabric for insertion into your ASIC)
3) Design of FPGA fabric service (as in competing with Pilkington, another
loser organization)
I don't think they knew either.
Here's my theory (it's "Just a Theory", so you can replace it with anything
you like :-)
Philip Says:
"FPGAs are such incredibly complex parts to design right, and have such
extensive software, support, applications, IP, education, and etc...
that unless it is ALL that you do, you will fail"
Your whole company has to be mono-focussed on FPGAs just to survive.
AMD/MMI tried and failed
Intel tried and failed
Ti tried and failed
Motorola tried and failed
National Semiconductor tried and failed
Toshiba tried and failed
NEC tried and failed
Plessy tried and failed
HP tried and failed
ATT tried and failed
Philips/Signetics tried and failed
Waferscale tried and failed
Cypress tried and failed
(I wonder who I have forgotten from this list that will be upset?)
Atmel tried and hasn't yet failed, but it does not look good.
The above list is of companies that do/did other stuff, and then
tried to do FPGAs as well. There are of course a long list of
startups that only wanted to do FPGAs, that have either failed,
been acquired, or continue to dig through the scraps that Xilinx
and Altera and Lattice miss.
When Pasquale Pistorio (ST President and CEO) in January 2004
said that they would be doing FPGA's I had a good laugh
http://tinyurl.com/ch3a7
because My Theory says they will fail.
"The move follows the shut down of an expensive, ill-fated R&D
effort aimed at putting ST into the FPGA market."
http://www.embedded.com/showArticle.jhtml?articleID=163105052
When ST announced that they were going to make their tool chain
public domain "to encourage research" it certainly did not sound
like "Plan A" :-)
So in answer to your question Antti, My Theory says ST will be
the next one to pull the plug, or more likely, it will just
quietly die away, and you will stop seeing press releases.
The products that have FPGA + something else integrated together
will be custom type parts (ASIC) that no-one will order.
Just a Theory,
Philip Freidin
Article: 91057"Philip Freidin" <philip@fliptronics.com> wrote in message news:m3p2m1lpf684v3ep3ap4gh7pcplr9hnnro@4ax.com... > Your whole company has to be mono-focussed on FPGAs just to survive. > AMD/MMI tried and failed > Intel tried and failed ... > (I wonder who I have forgotten from this list that will be upset?) Vantis -- bought out by Lattice before their FPGA ever made it to production. (Anyone out there ever get engineering samples?) Vantis did have various useful, inexpensive CPLDs that I designed into several products over time. > Atmel tried and hasn't yet failed, but it does not look good. Their FPSlic product is unique enough it probably won't die anytime soon. It's kind of a "gentle introduction to SOC design," IMO -- much easier to get into then one of the ARM or PowerPC + massive FPGA offerings. > The above list is of companies that do/did other stuff, and then > tried to do FPGAs as well. Ah... so maybe that does cover Vantis? ---JoelArticle: 91058
What version of wine ships with suse? I've just tried the wine 0.9, and it dies in weird ways. I'm simply doing a 'make -f system.make bits'. cheers, aaronArticle: 91059
On Thu, 27 Oct 2005 19:01:13 -0700, "Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote: >"Philip Freidin" <philip@fliptronics.com> wrote >> Your whole company has to be mono-focussed on FPGAs just to survive. >> AMD/MMI tried and failed >> Intel tried and failed >... >> (I wonder who I have forgotten from this list that will be upset?) > >Vantis -- bought out by Lattice before their FPGA ever made it to production. >(Anyone out there ever get engineering samples?) Vantis did have various >useful, inexpensive CPLDs that I designed into several products over time. Actually, I did not miss Vantis. Vantis is Plan C from the MMI acquired by AMD, merged into AMD PLD Division, spun out as a wholly owned subsiduary so that they could develop a sales force separate from AMD's (so that it would be a more valuable acquisition offering (not much value as an AMD division with no sales force included)), then separated from AMD (no buyer) and on its own for a while, then acquired by Lattice. The Vantis FPGA was actually that group's second attempt at an FPGA. I believe there was a prior product back when the group was an internal division within AMD. >> Atmel tried and hasn't yet failed, but it does not look good. > >Their FPSlic product is unique enough it probably won't die anytime soon. >It's kind of a "gentle introduction to SOC design," IMO -- much easier to get >into then one of the ARM or PowerPC + massive FPGA offerings. My lack of enthusiasm for Atmel is based on the functionality of their FPGA offering only. I hope the rest of Atmel does well, but I expect that the FPGA offering, and the derivative products will eventually go by the wayside. >> The above list is of companies that do/did other stuff, and then >> tried to do FPGAs as well. > >Ah... so maybe that does cover Vantis? Well, more of an exclusion, since at least for some part of its life Vantis could be considered in the "Startup only doing FPGA/CPLD" category. PhilipArticle: 91060
hi, I have a small query in VHDL language. Like we write in Verilog fifo_data <= 16'hAA4F; How can i write this in VHDL.???? The signal fifo_data is a vector of 16 bit length . Writing it as fifo_data <= 16#AA4F# gives a error when my signal is a std_logic_vector. If i change it to integer ,it worksArticle: 91061
anupam wrote: > hi, > I have a small query in VHDL language. > Like we write in Verilog > fifo_data <= 16'hAA4F; > How can i write this in VHDL.???? > The signal fifo_data is a vector of 16 bit length . fifo_data <= X"AA4F"; Regards, MarkArticle: 91062
On 26 Oct 2005 16:12:34 -0700, "ashwin" <achiluka@gmail.com> wrote:
>Hello everyone,
>I am trying to transfer data between on board ethernet PHY and the PC.
>For that i am implementing ethernet packet generator in the fpga. The
>MII interface on the fpga has transmit data bus of width 4 bits. So i
>am sending 64 bytes of frame from the fpga with the most significand
>bit transmitted first.
My understanding is that the data is shifted out LSB first, which would
require you to send the low order 4 bits first.
>As you all know ethernet frame consists of
>
>preamble,startframe,destination ad,source ad,length/type,data,crc
>
>Is this what each block consists of
>
>preamble - 7 bytes - x"5";
you mean x"55"
>
>startframe - 1 byte -x"5d";
Given my belief that data is sent LSB first, this would be x"d5"
>destination - 6 bytes - PC mac address
>
>source - 6 bytes -- any choice of fpga mac.(any value)
>
>length/type - 2 bytes -- "0000_0000_0100_0000"
>
>data - --38 bytes -- any value
>
>crc - 4 bytes
Actually, what is sent is the FCS, which is bit reversed
version of the CRC.
>2) Is CRC implemented on only data or on whole frame?
CRC starts with the destination address
>3) Can anyone guide me on how crc is computed?
>From the spec:
3.2.8 Frame Check Sequence (FCS) field
A cyclic redundancy check (CRC) is used by the transmit and
receive algorithms to generate a CRC value for the FCS
field. The frame check sequence (FCS) field contains a
4-octet (32-bit) cyclic redundancy check (CRC) value. This
value is computed as a function of the contents of the
source address, destination address, length, LLC data and
pad (that is, all fields except the preamble, SFD, FCS, and
extension). The encoding is defined by the following
generating polynomial.
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 +
x8 + x7 + x5 + x4 + x2 + x + 1
Mathematically, the CRC value corresponding to a given frame
is defined by the following procedure:
a) The first 32 bits of the frame are complemented.
b) The n bits of the frame are then considered to be the
coefficients of a polynomial M(x) of degree n.1.
(The first bit of the Destination Address field
corresponds to the x(n.1) term and the last bit of
the data field corresponds to the x0 term.)
c) M(x) is multiplied by x32 and divided by G(x), producing
a remainder R(x) of degree .31.
d) The coefficients of R(x) are considered to be a 32-bit
sequence.
e) The bit sequence is complemented and the result is the
CRC. The 32 bits of the CRC value are placed in the
frame check sequence field so that the x31 term is the
leftmost bit of the first octet, and the x0 term is the
right most bit of the last octet. (The bits of the CRC
are thus transmitted in the order x31, x30, ... x1, x0.)
You will notice the amazing fact that unlike the rest of
the frame that is sent LSB first, the FCS is sent MSB first.
>4) If CRC is wrong, will the PHY still transmit the data onto the PC.
Yes. The PHY does not care, and since it doesn't see the FCS
until the end of a packet, how would it know not to send the
earlier stuff :-)
>I would request you to please answer my questions as soon as possible.
Sure.
Bet the following helps too. Here is a REAL packet!!!
55
55
55
55
55
55
55
d5
0d
0d
0d
0d
0d
0d
0c
0c
0c
0c
0c
0c
88
08
00
01
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
e5
5c
0b
f8
The calculated CRC is 58 c5 2f e0
so the calculated FCS is e5 5c 0b f8
Let me work the first byte for you:
58 complemented is A7 == 10100111
Then reverse the bit sequence == 11100101
which is E5, which is then the first byte of the FCS
that is sent out, LSB first, which means it goes out as
1, 0, 1, 0, 0, 1, 1, 1. Thus meeting the requirement
that the first transmitted bit of the FCS is from the
MSB of the CRC. The standard specifies what must happen,
but not how. Since I didnt want to have a shifter for the
FCS that was different from the rest of the packet, I
instead supply the FCS to the shifter in reverse byte order
(MSByte first), and by bit reversing the byte, the shifter
can shift out LSBit first and achieve the requirement of
the FCS effectively shifting out MSBit first.
>thanks
>ashwin
Have fun, I certainly did.
Philip
Article: 91063Hello, Thanks for all your answers. So, as I understand, there is no any specific idea bihind this coding style for ASICs. That is good to know. >From the beginning I thought that this codding style is required for purposes of verification, testing or whatever else. With best regards, - VladimirArticle: 91064
Bevan Weiss schrieb: >> Not so for single cycle multipliers. For any practice multiplier size >> the number of 1-bit adders is fixed and there exists a complete set >> of transformations to automatically reach all possible setups even after >> placement. > > > So you're saying it makes no difference if booth encoding is used, or > any form of carry ripple reduction? That it's all just a rearranging of > wires? Surely not, using a booth encoder requires different components > to a simple ripple counter and so has broken that theory. You are right, my definition was not exact enough. What I wrote applies to anything that happens after partial product generation. Carry ripple reduction does not apply to single cycle multipliers. You need to sum up all carries at the end. Producing a redundant number representation at the output does not count, because now you changed the function computed by the circuit. Kolja SulimmaArticle: 91065
"Emtech" <noaddress> skrev i meddelandet news:435cb632@news.eftel.com...
>I have an application where I need to implement 24 or up to 32 PWM outputs
>(8-bit) and
> am considering using a small CPLD to handle the PWMs instead of doing it
> all in software.
> This does add a CPLD to the design, but frees the micro do to other
> things.
>
> Any recommendations on the CPLD & CPLD size without completing the VHDL
> first?
>
If you want to use a minimal amount of CPU power, then
you could connect a CPLD to a time slot bus and transfer frames of 32 x 8
bit = 256 bits
containing the PWM data.
The CPLD would contain
An 8 bit counter for determining bitnumber in each frame.
The upper 5 bits select PWM output
An 8 bit PWM counter.
Each PWM value is compared to the PWM counter and the PWM output bit is
set if the value is less than the PWM counter.
32 PWM outputs
A 64 macrocell CPLD should do the job.
You can get an I2S function in an AT91SAM7S321 ARM micro
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB
Article: 91066Ah, the board is already in the pre-series stage, there are a couple of reasons why we chose a 9500 CPLD (yes I know, very old!)... 5V internal = only one PSU needed & whole board at 5V which is excellent for reliability, our radiation campaigns showed that it's highly immune to soft-errors (TID was much more effective), It's active almost as soon as it is powered up whereas FPGAs must wait whilst they are being programmed. And we simply don't need the complexity of an FPGA. Don't get me wrong, we use all manner of Xilinx stuff in the lastest project (95288 95144XL XC2C128 XC2S400 XC3S1000) just depends on the exact nature of the application. I think I might investigate the Microprocessor alternative, just then have to figure out how to get the .bit file into some flash near the microprocessor in a reliable and easy manner. Ah well. Ben "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> wrote in message news:djrarf$a2r1@cliff.xsj.xilinx.com... > OK. Fair enough. And you could use SystemACE to do all that except for > programming the CPLD. Why use a CPLD and not just a small, cheap FPGA > like a Spartan3 or a variant? > > > Benjamin Todd wrote: >>>As also indicated, an interesting question to ask is why do you want to >>>configure your CPLD every time you power up? Is your design pattern >>>changing all the time? Is this some sort of demo board? >> >> >> Not exactly, maybe i'm being a little ambitious... >> >> I'm just doing some research into making a test apparatus for some >> designs using various CPLDs. The idea was to make a discrete piece of >> hardware that the UUT would be plugged into, and then a little report >> saying whether it passes or fails - this needs to be rugged, and >> industrialised. >> >> Using boundary scan I can only verify about half the board, and the less >> critical half at that, so i'm wondering whether I could use one bit file >> to run a sequence of test vectors in conjunction with the external >> tester, and then once all the interconnects are established as correct, >> load the proper bit file. >> >> I guess you're wondering why I don't just go for a PC running impact... >> well i'm trying to avoid having to maintain a PC with the manufacturer, >> including the OS, the test software etc etc. >> >> Ben >> >> >> >>Article: 91067
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:djqr4n$h7b1@xco-news.xilinx.com... > Antti, > > But "partially faulty" yet 99.999% tested (much better than an ASIC is > able to be tested) means that any faults which are not being used, don't > matter. > > Every Altera FPGA sold has a redundant column to replace a faulty one. > So, every one they sell could have a fault. But it isn't used. And it > does not affect reliability (as shown by their product qual tests). > > Easypath has also been fully qualified by the reliability testing that > is required of any device. > > Austin > Hi Austin, relax -I did not mean to say the easypath are bad or faulty, sure they are fully tested and OK, just they have nothing in common with ASICs. as of faulty bits - I would welcome if Xilinx would actually sell 'known bad silicon'. That is devices that have either known failures or some % of fails per chip. Such silicon could be sold 'as is'. Saying that this batch has say no more than 3% of LUTS failing, and there are no more than 0.1 interconnect bads... its up to the customer to test the chip and to develop methods how to to use it. I bet Xilinx marketing doesnt like the idea. Idea itself IS GOOD. With proper tools and sw technologies the 'faulty' FPGAs could still be used for many applications. AnttiArticle: 91068
Hallo, is there anybody who can help me to find out the scheme of a 16-bit delta-sigma adc? I have already made some searches into google but I don't have found interesting informations. Many Thanks Marco ToschiArticle: 91069
Antti, Selling known bad parts is an interesting concept. No one has figured out how to do that. You might talk to Peter about your ideas. Austin Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:djqr4n$h7b1@xco-news.xilinx.com... > >>Antti, >> >>But "partially faulty" yet 99.999% tested (much better than an ASIC is >>able to be tested) means that any faults which are not being used, don't >>matter. >> >>Every Altera FPGA sold has a redundant column to replace a faulty one. >>So, every one they sell could have a fault. But it isn't used. And it >>does not affect reliability (as shown by their product qual tests). >> >>Easypath has also been fully qualified by the reliability testing that >>is required of any device. >> >>Austin >> > > > Hi Austin, > > relax -I did not mean to say the easypath are bad or faulty, sure they are > fully tested and OK, just they have nothing in common with ASICs. > > as of faulty bits - I would welcome if Xilinx would actually sell 'known bad > silicon'. That is devices that have either known failures or some % of fails > per chip. Such silicon could be sold 'as is'. Saying that this batch has say > no more than 3% of LUTS failing, and there are no more than 0.1 interconnect > bads... its up to the customer to test the chip and to develop methods how > to to use it. I bet Xilinx marketing doesnt like the idea. Idea itself IS > GOOD. With proper tools and sw technologies the 'faulty' FPGAs could still > be used for many applications. > > Antti > > > > > > > > > > > > > > > >Article: 91070
I'm wondering if anyone here has ever used Mitrion-C to implement algorithms on FPGAS? If so, what kind of performance have you been achieving. Cheers, RobinArticle: 91071
Benjamin, I have made/written tools to program some of the Coolrunner CPLDs, I have them running on either a CPU32 (683xx) or PPC based system. Please feel free to contact me directly if you think I might be of some help. Regards, Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 91072
Hello Everyone,
I have few questions regarding the DP83847 PHY. I have this PHY on
xilinx virtex fpga board.
The data sheet is on this link
http://www.national.com/ds/DP/DP83847.pdf
I need to write an ethernet mac in the fpga to send the packets to the
PC through the PHY. Initially, to start with i am implementing the
transmit module.
1) when i hardware reset the PHY, the link estabilishes between the PC
and the fpga board, but whatever data i put on the MII interface on the
TXD(3:0), i am not able to see anything when i check the pin
TD+- in the oscilloscope. For some reason the PHY is not transmitting
the data.
a) Do i need to initialize the PHY before/after i hardware reset
it. If yes how?
b) By default , if i hardware reset, the PHY will act in 100 mbps
full duplex mode. So i guess , just to test this PHY, i dont have to
use MDC and MDIO right?
c)Do i need to exactly send the ethernet packet format to the PHY
inorder to test it correctly with the oscilloscope or will i be able
to see any data if i check it in the oscilloscope?
d) will i see a sinusoid on the TD+ pin when i check it in the
oscilloscope or is it a square wave.
I would appreciate , if you could please answer my questions as soon
as possible.
Article: 91073What you have the CoolRunner will not work for the xc9500 family because the configuration algorithms are radically different. dp wrote: > Benjamin, > I have made/written tools to program some of the Coolrunner > CPLDs, I have them running on either a CPU32 (683xx) or > PPC based system. Please feel free to contact me directly > if you think I might be of some help. > > Regards, > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ >Article: 91074
Hi folks, Just to advise that I'm working offline with this XPower user. Brendan "Pasacco" <pasacco@gmail.com> wrote in message news:1130251213.499890.218530@z14g2000cwz.googlegroups.com... > dear > > Before opening case, i would try fixing warnings. > Warnings 410,163,164 are very weird, > since i am using Xpower 6.3.03i, xc2vp30-7ff896..and the logic is > simple counter... > Any suggestions will be nice...Thankyou >
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