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
In article <M5P65.1136$HR.19533@news6-win.server.ntlworld.com>, "gary" <dont.spam@me.net> wrote: > Dear all, > > I am considering implementing an MPEG layer 2 audio decoder in an fpga. > Around 128kbit/s. > > What I need to know is.... > > (1) How complex is the decoder, how much logic would I need? I think with highly optimized design you should be able to do the audio decoder layer-I, not sure about layer-II, in around 8K gates or so. I am not thinking about the space to store constants here. See: http://www.tsec.com/p_audio.htm > > (2) Do you have to pay to use MPEG in your own codecs? You have to pay only if you buy the standards from ITU. which are priced at around $125. But you can get the know-how by some other means such as free sources on web. > > All help much appreciated. > > Gary. > > Good luck, Santosh Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23676
Hi ! Since Virtex-E does not allow to be used in PCI systems with 5V signaling level, I search for (cheap) motherboards with 32bit/33MHz PCI slots that have 3.3V signaling level. (We don need more bandwidth and want to use Virtex-E because its cheaper than our currently used Virtex.) Perhaps there are none and only 66MHz PCI systems use (require!) 3.3V signaling. Any (cheap) motherboards that supply this ? Thanks, TobiasArticle: 23677
As with many others here I don't think you will have any problem in reading the PROM but . . . The main problem may be in the data management and programming of the proms. As your proms will no longer be identical yo will not be able to use a gang programmer and creation of unique data streams for each prom may be a real PITA. H/W upgrades also become a problem eg. do you want an upgraded board to bear the same serial no as before? Proms cannot be sent out to third parties for upgrade. These things are not really something you want on a volume product - is that a problem. In a similar situation I have stored s/n etc in a little bit of EEprom in a Dallas RTC - not much use if you don't want an RTC, but other incredibly small (and cheap!) devices might suit your needs. Dave dmacArticle: 23678
Hi Kent,
korthner@my-deja.com wrote:
> I'm trying to think up a not-too-difficult way of adding a serial
> number to the Serial PROM used to program a Xilinx Spartan FPGA.
>
> The intent would be to use this as the Card Serial number, and once the
> FPGA was initialized, it would then go and read the PROM itself.
If the PROM is a XC18V00, there are 32 bits of user-defined data in the
form of the JTAG instruction USERCODE (is 32 bits enough?). The resulting
bitstream will of course be slightly different for each PROM, although I
believe USERCODE can be modified after configuration (confirm with Xilinx
first). If so, a single bistream may gang-program multiple PROMs, then each
PROM could be updated later in the process with its own serial number.
JTAG must be used to readback the usercode from the FPGA. You don't need a
full-fledged JTAG controller on your board, however, since you could add to
your FPGA design a small core that serially shifts out/in the proper values
to issue a USERCODE instruction to the PROM. You just need to be careful
because you don't want to mess around with your JTAG signals.
Just my 0.02$...
Regards,
Étienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 23679Hello, I search someone who was make a parallele cable III (HW-JTAG-PC) Xilinx. If YES a this question. Have you use this cable with free webpack soft xilinx. B.Bertrand bertrand@olfac.univ-lyon1.frArticle: 23680
XESS Corp. is releasing the second section of its "myCSoC" tutorial for free downloading at http://www.xess.com/myCSoC-CDROM.html. We will release a new section each week. Each section describes a design example for the Triscend configurable system-on-chip device (CSoC). The Triscend TE505 CSoC integrates an 8051 microcontroller core with a programmable logic array to create a chip whose software and hardware are both repr ogrammable. The tutorial examples show how the Triscend FastChip development software is used to configure the TE505's programmable logic into peripheral functions that cooperate with the microcontroller core. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 23681
In article <3962BAA9.4FBDB7C1@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: > I disagree that you can't get 100% coverage for test. I don't think Phil or I said that it can't be done, but depending on the situation it can take twice as much (or more) work to test 100% than to test 99%. Often it is acceptable to achieve a reasonable level of coverage. It's a tradeoff between fault coverage and project development time/cost. > I am sure that Xilinx tests every chip they make 100%. I sure as heck hope so :-) > Since the chip is fully > programmable, I doubt that they needed to design in special test > circuitry or modes. I would bet my last dollar that the tools and information that Xilinx test engineers have at their disposal are far better than what we have. > Certainly this may take more than a single bit file. > But I am sure that you can test every transistor, every wire and every > connection in a Xilinx FPGA if you need to do that. > > As I said in my other post, I once met an engineer who was designing bit > files for Xilinx chips to do 100% test in military systems. They would > do a complete test of the hardware every time they powered up. I think > this was in the XC3000 and XC4000 parts. > I sent a reply to that post, but it looks like it got lost in the ether. Anyway, I'm sure that it is possible to do, if you have the right tools and information. Peter said it could be done, but he didn't give us any pointers as to how to do it properly. It seems to me that it would be a very long, tedious process to ensure that your bitstream tests all (or even 99%) of the transistors on the FPGA, using the P&R tools that are supplied to us by Xilinx. I would love to see your associates' V&V of his test methodology and coverage. I prefer to build BIST logic into the mission bitstream, so that the logic and interconnect that are in use can be tested, without having to worry about testing resources that are not in use. Also, the test logic becomes part of the documentation and V&V process for the mission logic, so a separate set of documentation is not needed for functional test design(s). -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23682
Greg Neff wrote: > > In article <3962BAA9.4FBDB7C1@yahoo.com>, > Rickman <spamgoeshere4@yahoo.com> wrote: > > I disagree that you can't get 100% coverage for test. > > I don't think Phil or I said that it can't be done, but depending on > the situation it can take twice as much (or more) work to test 100% > than to test 99%. Often it is acceptable to achieve a reasonable level > of coverage. It's a tradeoff between fault coverage and project > development time/cost. Yes, it is certainly a nearly asymtotic function where it gets harder and harder to cover the entire chip in one design (or impossible). But the beauty of an SRAM based chip is that you can design multiple bitfiles and (likely) get 100% coverage very easily (in relative terms). > > I am sure that Xilinx tests every chip they make 100%. > > I sure as heck hope so :-) > > > Since the chip is fully > > programmable, I doubt that they needed to design in special test > > circuitry or modes. > > I would bet my last dollar that the tools and information that Xilinx > test engineers have at their disposal are far better than what we > have. Certainly they have better info. But I would bet that info is available under NDI. The person I met who was doing this had gotten a lot of info from Xilinx. > I sent a reply to that post, but it looks like it got lost in the > ether. Anyway, I'm sure that it is possible to do, if you have the > right tools and information. Peter said it could be done, but he > didn't give us any pointers as to how to do it properly. I agree that it would take support from Xilinx. I wouldn't have an idea of how to test all the interconnect in an FPGA. When I use the chip editor, I don't even understand all of the connections! I really don't see how people can hand route chips. I used to know someone who did that, always! > It seems to me that it would be a very long, tedious process to ensure > that your bitstream tests all (or even 99%) of the transistors on the > FPGA, using the P&R tools that are supplied to us by Xilinx. I would > love to see your associates' V&V of his test methodology and coverage. > > I prefer to build BIST logic into the mission bitstream, so that the > logic and interconnect that are in use can be tested, without having to > worry about testing resources that are not in use. Also, the test > logic becomes part of the documentation and V&V process for the mission > logic, so a separate set of documentation is not needed for functional > test design(s). Certainly BIST scan based logic is much easier than trying to do 100% coverage testing, but the full coverage testing will work with any design in that chip and not use any resources in the running design. I would love to hear from Peter Alfke about the willingness of Xilinx to share their test info for bit files that users can use to do 100% coverage testing of the chip. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23683
Rickman wrote: > I would love to hear from Peter Alfke about the willingness of Xilinx to > share their test info for bit files that users can use to do 100% > coverage testing of the chip. Yes, I have helped people get that information, usually under non-disclosure (NDA). As Xilinx gets bigger, the procedure may have gotten more complicated. Please contact Marketing with a formal request. I cannot help you now, because I am on vacation, jumping on an airplane in a few hours. Destination: Provence. I may need retraining when (if) I came back. :-) Peter AlfkeArticle: 23684
"Jan Gray" <jsgray@acm.org> wrote in message
news:vWe85.1205$q94.384510@paloalto-snr1.gtei.net...
> n w 8-back
> - - ------
> 0 0
> 1 1
> 2 3
> 3 7
> 4 E
> 5 D
> 6 B
> 7 6
> 8 C 0
> 9 9 1
> 10 2 3 8-cycle [2-9]: complement d0 when w==9 maps 2=>3
>
> lfsr 4-bits 8-cycle=9
> lfsr 4-bits 8-cycle: d0=xnor(q3,q2, /*9*/and(q3,~q2,~q1,q0));
>
> Here w[2]=3, w[9]=9, and w[10]=2. If we complement the lfsr input bit
shift
> into w[10], we would have w'[10]=3 and the lfsr would cycle
> 3,7,E,D,B,6,0,1,3,...
Correction: 3,7,E,D,B,6,C,9,3, ...
One other comment. If you build an m-cycle n-bit lfsr with m < 2^n - 1, and
reset it to the bit pattern 0000...0, and if 0000...0 is not in the m-cycle,
then it may take up to 2^n - m-1 cycles for the counter to first reach a
valid m-cycle bit pattern. In the above example, it takes 2 cycles for the
lfsr to first reach an m-cycle bit pattern 0x3, and 9 cycles (9 > 8) to
first reach the terminal m-cycle bit pattern 0x9.
If you were to design, e.g. a 3-cycle 6-bit lfsr (for some strange reason)
such as
lfsr 6-bits 3-cycle: d0=xnor(q5,q4, /*2D*/and(q5,~q4,q3,q2,~q1,q0));
it takes 37 cycles before it reaches the bit pattern 0x1B and starts its
3-cycle (0x1B, 0x36, 0x2D, 0x1B, ...). If this is not acceptable, you must
of course ensure you reset the lfsr to some valid bit pattern in the
m-cycle.
Jan Gray
Gray Research LLC
Article: 23685On Wed, 05 Jul 2000 01:45:26 -0400, Rickman <spamgoeshere4@yahoo.com> wrote: >korthner@my-deja.com wrote: >> >> Thanks for the advice, Rick. >> That's what I was thinking of doing. I know that I can't drive CCLK >> after startup, and one of the others (Forget which), so I figured I'd >> connect them to an extra FPGA pin(s). > >PROG-, DONE, CCLK are the ones that can't be used for anything else. >Also DOUT I think. INIT- and DIN are user IOs after config. So you would >need to provide a user IO connections to DONE/CE- and CCLK/CLK. > > >> And figured I'd put the serial number in the last spot in the PROM, and >> at SerialNumberReading time, I would just shift everything into an n- >> bit shift register until the PROM was empty, and whatever was left in >> the shift register, that's my serial number. > >Yes, that would work fine. You will need a counter matched to the size >of your PROM to stop it. > What about just monitoring the CEO of the PROM, and then only shifting when CEO is high? Jason > >> I'm missing something, I think. I've seen other people mention using a >> micro to boot a FPGA. . . . . Why? If you're not using anything fancy >> like reprogrammability or readback, isn't it easier/cheaper to just >> plug a PROM in a socket, and let the FPGA suck up the bitstream itself? > >There is no reason to use a micro unless you can use it for some other >tasks as well. In my case I was looking for a way to replace the one >wire serial number part (in which I would also use the EEPROM/PROM) and >realized that it could replace a couple of other parts. Now I am looking >for the perfect uC that will replace all the misc logic chips on my >board. If I could find one that had three analog comparators as well as >the Flash, EEPROM, UART and a dozen or more IOs I would have it made. >But it is hard to find everything in one part. > > >> That's the other thing we're looking at. I assume, then, that you've >> got the Dallas part (2401?) up and running, no problem? Can you by any >> chance let me know how big the onewire-control logic inside the FPGA >> is? I have a *very* little amount of space left (20% of a Xilinx >> Spartan '05), so I figure I don't have what it takes to do the timing >> requirements. If you could send me a copy of the VHDL code, that'd be >> wonderful. But if you can't, I understand completely. > >The Dallas part is very easy to use. The documentation is not real clear >though. But you can read between the lines and figure out what is going >on. We used the on board DSP to do all this so I don't know how large >the circuit would be in an FPGA. > >You just need a few timers and a finite state machine (FSM). The one >wire chip communicates in a polled mode where every bit sent in either >direction is started by the FPGA with a one uS low pulse (all drivers >are OC and there is a single 4.7K pullup). In that 1 uS the one wire >chip will pick up the ball and drive it to a zero if it is sending you a >zero or leave it float if it is sending you a one. A zero is held for >another 15 uS max. If you are sending a zero or one, you do the same (1 >uS v. 15 uS). There is also a reset pulse sent to the one wire chip >which is a zero for over 60 uS. > >This is how you send/receive bits. There is then a protocol on top of >that to read the data in the one wire chip and to program it. If you >just need to read the serial number and nothing else, I think there is a >command to read it out cold. The other commands require you to "address" >the chip with the SN. > >This is all a bit hazy as it has been awhile since I looked at it and I >did not do the coding. But this is the jist of it. Certainly the bit >level is not hard to do if you have a clock handy (and who doesn't?). >The higher level protocol will take a bit of FSM design. > >But if you are short on free hours, I could do the VHDL for you. It >might even save you a little time/money since I have a leg up on the one >wire parts and I can even test the VHDL on my board. > >Maybe someone else has done this in VHDL? > > >-- > >Rick Collins > >rick.collins@XYarius.com > >Ignore the reply address. To email me use the above address with the XY >removed. > > > >Arius - A Signal Processing Solutions Company >Specializing in DSP and FPGA design > >Arius >4 King Ave >Frederick, MD 21701-3110 >301-682-7772 Voice >301-682-7666 FAX > >Internet URL http://www.arius.com Jason T. Wright Cygnion CorpArticle: 23686
I believe the defaul settings for par are different. Jason On Tue, 04 Jul 2000 10:22:34 +0300, Yekta Ayduk <yekta@netas.com.tr> wrote: >I installed Foundation 2.1i and all service packages ,but the placement >and routing results are worse in comparision to 1.5 . I used the >same table seed entry ,routing effort ,ucf files . The parts are XC5204 >and XS20 . >Did anybody get similar results? > Jason T. Wright Cygnion CorpArticle: 23687
"Jason T. Wright" wrote: > > On Wed, 05 Jul 2000 01:45:26 -0400, Rickman <spamgoeshere4@yahoo.com> > wrote: > >> And figured I'd put the serial number in the last spot in the PROM, and > >> at SerialNumberReading time, I would just shift everything into an n- > >> bit shift register until the PROM was empty, and whatever was left in > >> the shift register, that's my serial number. > > > >Yes, that would work fine. You will need a counter matched to the size > >of your PROM to stop it. > > > What about just monitoring the CEO of the PROM, and then only shifting when > CEO is high? > > Jason That's a good idea as long as you have the spare IO line. Saves a number of CLBs if you are tight on space. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23688
SteVe wrote in message <3961DD67.10F9889@xxx.it>...
>In my Virtex design (written in VHDL) I have a reset signal (N_RST).
>This signal is active low and resets all the FFs of the design,
>excluding a few of them (which haven't a set/reset signal).
>My question is: can I use the Global Set Reset resource? The problems I
>see are two:
>- the GSR net is active high, but my N_RST signal is active low;
An inverter will be inserted between your reset signal and the GSR.
>- the GSR net reaches all the FFs: what happens to the FFs of my design
>that have not a S/R signal?
The synthesis tool should complain that not all flops are set/reset by the
reset signal and it won't infer a global reset. You can fix that by
hand-instantiating the GSR or just making sure all flops have a reset (which
is preferred).
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke
Article: 23689Rickman <spamgoeshere4@yahoo.com> wrote: > I know what you mean, but this would make the complexity of inventory > very much harder. This is especially a big problem for micros, you need > to vary not only the RAM/ROM and all the usual things that micros > tailor, but you also need to vary the size of the FPGA and the package > pins (much more so than on a micro). They would have to do a sparse > matrix implementation of that N dimensional array. > > I do that Lucent is selling FPGAs not much different from Xilinx parts > that have an on board PCI bus interface. I don't know how well it is > selling though. Lucent seems to be very tight on information on new > products and sales. In keeping with their non-marketing strategy, Lucent announced their latest chip during a 5-day holiday. http://www.lucent.com/micro/NEWS/PRESS2000/070300a.html Which claims (in addtion to 4-port block ram and LVDS I/O): " ... and has built-in 8-bit, 16-bit and 32-bit interfaces to the PowerPC* 860 and PowerPC II microprocessors. It uses a new embedded AMBA** specification 2.0 AHB multi-master system bus to handle communication at rates up to 200 MHz between the microprocessor interface, configuration logic, all embedded-block RAMs, FPGA logic and embedded standard-cell blocks ..." This becomes very attractive for an embedded CPU + FPGA combination. Unfortunately, I have been fighting with the Lucent software for the past 2 weeks, and am just about ready to try brand X again. (Even though it takes an XCV800 to implement a circuit that fits in an OR3L165). -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 23690
Don Husby wrote: > In keeping with their non-marketing strategy, Lucent announced their latest > chip during a 5-day holiday. > http://www.lucent.com/micro/NEWS/PRESS2000/070300a.html > > Which claims (in addtion to 4-port block ram and LVDS I/O): > " ... and has built-in 8-bit, 16-bit and 32-bit interfaces to the PowerPC* 860 > and PowerPC II microprocessors. It uses a new embedded AMBA** specification > 2.0 AHB multi-master system bus to handle communication at rates up to 200 MHz > between the microprocessor interface, configuration logic, all embedded-block > RAMs, FPGA logic and embedded standard-cell blocks ..." > > This becomes very attractive for an embedded CPU + FPGA combination. > Unfortunately, I have been fighting with the Lucent software for the past > 2 weeks, and am just about ready to try brand X again. (Even though it > takes an XCV800 to implement a circuit that fits in an OR3L165). If this is what I think it is, you have the same capability on the OR3T family. They have the MPI, a built in interface for two uPs. "The MPI is programmable to operate with PowerPC MPC800 series microprocessors and Intel*i960* J core processors". You can use it to download the FPGA bitstream and then use the same interface to talk to the innards after configuration is complete. There is even an ID register to identify the specific FPGA in case you have multiple parts that will fit your "socket" on the board. It sounds like they suped it up a bit in the new version though. I never used the interface since it would have required me to emulate the same interface and I am using a DSP. The new chips sound like they will continue to give Xilinx a run for the money in the large telecom accounts. But there will not be much for the small guys like us. (I guess I should speak for myself!) I currently am using a couple of the Lucent parts on a board I build. I recently asked Lucent if they could meet the pricing that I can get on similar new Spartan II parts. They were unwilling to do that on the larger of the two parts and in fact raised the price on me. So I will likely be switching when the new Xilinx parts are out. The bottom line is that Xilinx has a much larger volume (I assume) than Lucent and will continue to support a broad range of parts in different sizes, packages (although not as many combos as I would like) and new technologies. And on top of it, they seem to be committed to keeping a low priced line available. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23691
Phil,
As usual, you hit the nail right on the head. Maybe I'm oldfashioned but I
like to see the results of each synthesized block. Now I can get my post
synthesis schematic into simulatable form. To do it I had to use the updated
Virtex library from Xilinx and update the Viewlogic Fusion simulator and
Viewlogic edif reader. I did the Viewlogic updates through the Webupdate
utility but it was ten's of megabytes.
In addition to all that, I had to add the line below to my edifatts.cfg file
.
INIT\=@INIT
I have put a .pdf copy of the Viewgen'ed schematic up on my web site
(http://home.att.net/~padudle/big_add4.pdf) so you see what the output looks
like. I tested it in the simulator and it works correctly!
Thanks to all for the help.
********************************************************************
Pete Dudley
Sandia National Labs
Dept 2336 MS 0505
PO BOX 5800
Albuquerque, NM 87185
voice: 505.844.5565 fax: 505.844.2925 email: padudle@sandia.gov
http://www.sandia.gov/RADAR/sarcap.html
Signal Processing in Hardware and Software
********************************************************************
"Philip Freidin" <fliptron@netcom.com> wrote in message
news:8jmabg$lip$1@slb7.atl.mindspring.net...
> In article <8jm9qe$ji0$1@slb7.atl.mindspring.net>,
> Philip Freidin <fliptron@netcom.com> wrote:
> >
> >The latest version of ViewSim, and the latest version of the Virtex
> >libraries are supposed to be able to simulate ROMs with init=xxxx
> >attributes attached. This was fixed about 6 months ago. No announcement
> >was made, so you just needed to trip over the updates.
> > ... more helpful stuff deleted ...
>
> You might also want to look at http://support.xilinx.com/techdocs/5968.htm
>
> Philip Freidin
>
Article: 23692
Rickman wrote in message <395ED46E.D072C66A@yahoo.com>...
>Now if I can just get them to let me enter a single equation for the LUT
>instead of having to calculate the hex contents myself.
FPGA Editor?
--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke
Article: 23693Has anyone ever ran a timing simulation using wildforce reconfigurable computing boards, the timing simulation which incorporates the PE_logic_core design as well as simulation model of the board?? --AnuragArticle: 23694
I was reviewing the LFSR Testbench by Jean Nicolle and I am not sure,
but I thought there might be a bug in some of the VHDL code it
generates.
The program seems to be very flexible. It allows you to design any of
several forms of LFSRs and will show you a schematic of the design
generated as well as code in AHDL, VHDL and Verilog. VHDL is the only
one I am familiar with and I thought there might be a bug in the clocked
process. The variable "feedback" is assigned a value inside the if
clock'EVENT statement which seems to me will generate an additional,
unwanted FF. The only FFs in the design should be LFSR(0:3). Am I right
or is this code fine?
You can find the program at http://www.jps.net/kyunghi/LFSR/. Check it
out!
entity LFSR4_9 is
port(clock: in bit;
q : out bit_vector(3 downto 0));
end;
architecture RTL of LFSR4_9 is
signal LFSR: bit_vector(3 downto 0);
begin
process(clock)
variable feedback: bit;
begin
if clock'EVENT and clock='1' then
feedback := LFSR(3);
LFSR(0) <= feedback;
LFSR(1) <= LFSR(0) xor feedback;
LFSR(2) <= LFSR(1);
LFSR(3) <= LFSR(2);
end if;
q <= LFSR;
end process;
end;
--
Rick Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
Internet URL http://www.arius.com
Article: 23695On the schematic!!! Andy Peters wrote: > > Rickman wrote in message <395ED46E.D072C66A@yahoo.com>... > > >Now if I can just get them to let me enter a single equation for the LUT > >instead of having to calculate the hex contents myself. > > FPGA Editor? > > -- > ----------------------------------------- > Andy Peters > Sr Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) noao \dot\ edu > > "A sufficiently advanced technology is indistinguishable from magic" > --Arthur C. Clarke -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23696
Tobias-Dirk Stumber wrote: > > From some experiments with a controllable power supply, I came to have a > > mere conjecture that the 2.5V power supply from a linear regulator(LT1076) > > is not really tracking fast enough to meet the changes in Virtex' current > > consumption. When the 2.5V power is supplied from power supply, the card > > kept working over night. > > Are you completely sure your card fails because of power supply problems ? > You could propably check this with a dummy design for your virtex with a lot > of noise (toggle-flip-flops etc.) > > In "massive test operation" a lot of systems fail after a undefinable time > (minutes > to days). Ours did, too. But at last it was an interrupt handling problem > which was > caused by an extremely rare combination of things happening at the same > time. > Your problem may be of this nature, too. > Another thing is that even slight variations in power supply, temperature etc. can expose problems with FFs used to sample asynchronous data.Article: 23697
Hi, Rickman <spamgoeshere4@yahoo.com> wrote in message news:3963AA1C.75948386@yahoo.com... > I was reviewing the LFSR Testbench by Jean Nicolle and I am not sure, > but I thought there might be a bug in some of the VHDL code it > generates. > > The program seems to be very flexible. It allows you to design any of > several forms of LFSRs and will show you a schematic of the design > generated as well as code in AHDL, VHDL and Verilog. VHDL is the only > one I am familiar with and I thought there might be a bug in the clocked > process. The variable "feedback" is assigned a value inside the if > clock'EVENT statement which seems to me will generate an additional, > unwanted FF. The only FFs in the design should be LFSR(0:3). Am I right > or is this code fine? > I think the code is JUST FINE :-) Since the "feedback" is a VARIABLE and not a SIGNAL it shouldn't give you extra FF. Regards, Srini > You can find the program at http://www.jps.net/kyunghi/LFSR/. Check it > out! > > > entity LFSR4_9 is > port(clock: in bit; > q : out bit_vector(3 downto 0)); > end; > > architecture RTL of LFSR4_9 is > signal LFSR: bit_vector(3 downto 0); > begin > process(clock) > variable feedback: bit; > begin > if clock'EVENT and clock='1' then > feedback := LFSR(3); > LFSR(0) <= feedback; > LFSR(1) <= LFSR(0) xor feedback; > LFSR(2) <= LFSR(1); > LFSR(3) <= LFSR(2); > end if; > q <= LFSR; > end process; > end; > > > -- >Article: 23698
Rickman <spamgoeshere4@yahoo.com> wrote: > If this is what I think it is, you have the same capability on the OR3T > family. They have the MPI, a built in interface for two uPs. "The MPI is > programmable to operate with PowerPC MPC800 series microprocessors and > Intel*i960* J core processors". Yeah, except that the 3T is limited to an 8-bit data bus. With a high performance 32-bit CPU interface, it makes it feasible to interface the OR4T to your 32-bit DSP with minimum (hopefully 0) logic. > I never used the interface since it would have required me to emulate > the same interface and I am using a DSP. > > The new chips sound like they will continue to give Xilinx a run for the > money in the large telecom accounts. But there will not be much for the > small guys like us. (I guess I should speak for myself!) Historically, I think the price/performance of Orcas has been better than Xilinx (ie OR2 vs X4K/spartan), especially if you have high pin/logic ratio, or if you push them to the performance edge and diddle the mapping and placement. It looks like Xilinx is doing better with this generation, probably because Altera has released their own "Spartan" series. (Although I may learn otherwise when I port this design to Xilinx.) > The bottom line is that Xilinx has a much larger volume (I assume) than > Lucent and will continue to support a broad range of parts in different > sizes, packages (although not as many combos as I would like) and new > technologies. And on top of it, they seem to be committed to keeping a > low priced line available. Plus they seem to have a lot more (and better?) software support behind the chips. I especailly like the fact that Xilinx appears to allow exact mapping (e.g. put this signal on this CLB pin dammit!) to be specified in VHDL code. Lucent seems to have a long way to go with the OR3T PAR software. For example, it won't swap pins on a simple 8-bit D-register or tristate bus in order to meet timing. I ended up doing this myself by teasing the VHDL code, but it takes 1-2 hours of effort to get something like that right, and it will probably break when the next software version is released. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 23699
Tobias-Dirk Stumber wrote: > Hi ! > > Since Virtex-E does not allow to be used in > PCI systems with 5V signaling level, I search > for (cheap) motherboards with 32bit/33MHz > PCI slots that have 3.3V signaling level. > (We don need more bandwidth and want to > use Virtex-E because its cheaper than our > currently used Virtex.) > > Perhaps there are none and only 66MHz PCI > systems use (require!) 3.3V signaling. Any > (cheap) motherboards that supply this ? > > Thanks, > Tobias It would give you wider access to cheap motherboard if you buffer you PCI through QuickSwitch type parts. These, originally supplied by Quality Semiconductor - now part of IDT, are really just a bunch of pass transistors that clamp the output voltage to about Vcc-0.7. The trick is to set down from the nominal 5V to 3.9, they take almost no power so a simple Zener is sufficient. We have solved the 5V/3.3V PCI problem in this way for a long time as do a lot of [older] motherboards. Other suppliers of these type of parts are Pericom & Phillips.
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