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
David Ashley wrote: > Did you init the mutex? Is the mutex residing on some cacheable > memory, and the cache hasn't been flushed? On a POSIX-conforming system (ie. compiler + OS + hardware as a whole), the pthread API is sufficient to achieve synchronization. No low level trick are necessary. That's the whole point.Article: 108526
Antti wrote: > David, > > would you please please consider zipping all the stuff that is needed > to get ppc linux on the memec board running and uploading it? > I do have the same board so I could hopefully get a faster start. > Sure if there is anything I can offer in return please ask. > > Antti > Antti, Here's a link from the sourceforge u-boot mailing list archive http://sourceforge.net/mailarchive/forum.php?thread_id=10268159&forum_id=12898 In the little bit of time I spent I couldn't actually download the patch though...I've got to run right now but I'll dig up the code later. See if you can figure out how to get at the patch. There is also a very small chance they've already integrated it into u-boot. Very small... Anyway that gets you u-boot. I never released the linux patch since we opted to do our application inside u-boot and linux wasn't needed. I'll see what I can find... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108527
ryanrsrsrs@yahoo.com wrote: > David Ashley wrote: > >>Did you init the mutex? Is the mutex residing on some cacheable >>memory, and the cache hasn't been flushed? > > > On a POSIX-conforming system (ie. compiler + OS + hardware as a whole), > the pthread API is sufficient to achieve synchronization. No low level > trick are necessary. That's the whole point. > Well something's broken. The code ought to behave differently...At this point there are no options but grasping at straws... The init code wasn't included, you can't just declare a mutex, you need to initialize it: static pthread_mutex_t amutex=PTHREAD_MUTEX_INITIALIZER; For example... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108528
David Ashley wrote: > Well something's broken. The code ought to behave > differently...At this point there are no options but > grasping at straws... Check the behavior of sleep(). I take it sleep(500) is not meant to sleep for 500 seconds. POSIX sleep() has wierd interactions with setitimer(), ualarm(), usleep(), and SIGALRM. It can also return early due to signal delivery. Nanosleep() is easier to use. Try the following: lock print "begin thread %i" sleep print "end thread %i" unlockArticle: 108529
David Ashley wrote: > Antti wrote: > >>David, >> >>would you please please consider zipping all the stuff that is needed >>to get ppc linux on the memec board running and uploading it? >>I do have the same board so I could hopefully get a faster start. >>Sure if there is anything I can offer in return please ask. >> >>Antti >> > > > Antti, > > Here's a link from the sourceforge u-boot mailing list archive > http://sourceforge.net/mailarchive/forum.php?thread_id=10268159&forum_id=12898 > > In the little bit of time I spent I couldn't actually download the patch > though...I've got to run right now but I'll dig up the code later. > See if you can figure out how to get at the patch. > > There is also a very small chance they've already integrated > it into u-boot. Very small... > > Anyway that gets you u-boot. I never released the linux patch > since we opted to do our application inside u-boot and linux > wasn't needed. I'll see what I can find... > > -Dave > Antti, Here's the patch. The file should be renamed patch.gz or something like that, then you gunzip it, and that's the patch. http://cache.gmane.org//gmane/comp/boot-loaders/u-boot/21744-001.bin Boy this is way off topic for this newsgroup... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108530
Does anyone have any expereince/opinions with the mem_ctrl project in opencores? http://www.opencores.org/projects.cgi/web/mem_ctrl/overviewArticle: 108531
i am preparing for intervew and i want the answer how Barrel shifter can be used to optimize of C code at ARM processor. i have learnt that Barrel shifter is :A digital circuit that can shift a data word by any number of bits in a single cycle. It is implemented as a sequence of multiplexors: the output of one MUX is connected to the input of the next MUX in a way that depends on the shift distance. The number of multiplexors required is log2(n), where n is the computer's register size.Article: 108532
Ray Andraka wrote: > The SRL16's are actually one of the most versatile blocks on the FPGA. > You can use them for: > > reprogrammable LUTs --poor man's reconfiguration > dual port memory --serial write port, parallel read > synchronous FIFO --smallest FIFO implementation > data reordering --this is really cool for sorting and other apps > counters > state machines > variable delays > fixed delays Nice list. Care to elaborate on the "data reordering" use case? I can't think of any good examples. Thanks, TommyArticle: 108533
Tommy Thorn wrote: > > Nice list. Care to elaborate on the "data reordering" use case? I can't > think of any good examples. > > Thanks, > Tommy > OK, an example: A small FFT requires the input data in bit reversed order, however the circuit presents data in natural order: the data goes into the SRL16 in natural order, and then we permute the address for read so that it reads out in the bit reversed order input: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F output: 0 8 C 2 A 6 E 1 9 5 D 3 B 7 F address=delay-2 A 3 0 B 4 9 2 x 9 E 7 y B x 9 x=10h y=12h This case requires two cascaded SRL16's to get all the delays needed for the sequence. The address can be produced from an ordinary counter by passing the 4 bit count through a 4 input x4 bit LUT. Reversing the order of data in a set of 8 numbers (a left-right mirror) is similar, using just an SRL16 per bit and a 3 bit counter: input: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 output: 7 6 5 4 3 2 1 0 address=delay-2 0 2 4 6 8 A C EArticle: 108534
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1158088454.332189.307350@b28g2000cwb.googlegroups.com... > Ray Andraka wrote: >> The SRL16's are actually one of the most versatile blocks on the FPGA. >> You can use them for: >> >> reprogrammable LUTs --poor man's reconfiguration >> dual port memory --serial write port, parallel read >> synchronous FIFO --smallest FIFO implementation >> data reordering --this is really cool for sorting and other apps >> counters >> state machines >> variable delays >> fixed delays > > Nice list. Care to elaborate on the "data reordering" use case? I can't > think of any good examples. > > Thanks, > Tommy >From my own experience: A 2-D example using fixed length SRLs that comes to my mind is a 90 degree pixel rotation. If you have a 16x16 array of vectors that come in in the order A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 Aa Ab Ac Ad Ae Af B0 B1 B2 B3 B4 ... C0 C1 ... . . . P0 P1 P2 P3 ... And want to send them back out rotated 90 degrees so the order is A0 B0 C0 D0 E0 F0 G0 H0 I0 J0 K0 L0 M0 N0 O0 P0 A1 B1 C1 D1 E1 ... A2 B2 ... . . . Af Bf Cf Df ... You can do this completely pipelined for 16x16 blocks without intermediate load/unload cycles with 30 shift registers and a 16 bit barrel shift. The <100 LUTs is much better than the ~384 registers needed for the same functionality. ______ A 1-D example I was considering would use SRLs from byte wide Cyan, Magenta, Yellow, and Black lookup memory outputs (4 color printing) and rearrange into single-color words. This is effectively the 2-D rotate mentioned above, but the 8 instances of the 4x4 is small enough that I could effectively integrate half the fixed-length SRLs into dynamic length SRLs to feed the barrel shift. Direct memory output C0 M0 Y0 K0 C1 M1 Y1 K1 C2 M2 Y2 K2 C3 M3 Y3 K3 -- barrel shift -- C0 M0 Y0 K0 K1 C1 M1 Y1 Y2 K2 C2 M2 M3 Y3 K3 C3 -- dynamic srl -- C0 C1 C2 C3 M0 M1 M2 M3 Y0 Y1 Y2 Y3 K0 K1 K2 K3 It's cheaper to manipulate the addresses for 8 sets of SRLs than to increase the number of SRLs for the larger fixed 2-D example. - John_HArticle: 108535
Its not a big problem but annoying nonetheless. I installed the ISE 8.2 last week and have been using the view rtl schematic and view technology schematic features just fine since my install. Today, however, when I open up the schematics the page is blank. I have to zoom in or zoom to screen to see anything. And this doesnt always work. Of course, if it does work then I have to zoom back out to view the whole schematic (as I had to zoom once to get any sort of display) . This is getting to be really annoying. Especially when it does not display anything at all, no matter how much I click zoom and fit to screen. Does anyone know if I screwed something up, somehow? Is this just a bug? Thanks, ColinArticle: 108536
Thank you Austin and Peter for you replies. I still have 2 questions 1)a) So, you suggest using a 1k ohm serial resistor to interface the 5V signal to 2.5V input. May I know how you came to this number? b) For the 5V -> 3.3V interface, xilinx application suggests a Rser=3D300Ohm. Should I also replace this with a Rser=3D1kohm? 2)Why use a parralell resistor to the voltage regulator and waste power to handle the reverse current. Why not just add a reverse biased schotkey diode from the output to the input of the voltage regulator? Austin Lesea schrieb: > jidan, > > Peter makes a good point: if the resistance is too low, then you are > injecting current into the 2.5 V supply, and it may begin to drift up, > and out of regulation. > > One way to avoid that, and to avoid any rail supply being driven above > its intended output, is to balance the injected current with a simple > resistor across the power supply, present all the time. > > So, if you think you will inject 100 mA worst case into the 2.5V rail, > then plan on having a load of at least 100 mA on the 2.5 volt supply. > If the 2.5 volt supply has a minimum normal load of 50 mA, then you will > need an additional 50 mA load, just in case. 2.5V/.05=3D50 ohms (51 ohms, > nearest 5% value). > > All this because regulators are good at regulating a load, but incapable > of regulating when you source current into there output terminal. > > Austin > > Peter Alfke wrote: > > jidan1@hotmail.com wrote: > >> Hi, > >> > >> I would like to configure a spartan-3 FPGA with an 5V CMOS > >> microcontroller. I have read xilinx database answer regarding how to > >> make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm). > >> > >> 1) Can also the confg. dedicated pins made 5V tolerant through a serial > >> resistor although they are powered from 2.5V? (I calculated this an I > >> came to Rser=3D220OHM) > >> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is > >> (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? If y= es, > >> what IC's would you recommend? > >> > >> Regarding 1: > > I would use 1 kilohm. No need to push more current than necessary. > > Regarding 2: > > You quote worst-case numbers that assum lowest Vcc on the FPGA and > > higest possible Vcc on the uP. > > Keep the FPGA fed with at least 3.2 V, and you will see that same > > voltage on the output (this is CMOS !), and keep the uP Vcc slightly > > below 5V. > > But you will not have much noise immunity. > > Peter Alfke > >Article: 108537
Answers below, Austin jidan1@hotmail.com wrote: > Thank you Austin and Peter for you replies. > > I still have 2 questions > > 1)a) So, you suggest using a 1k ohm serial resistor to interface the 5V > signal to 2.5V input. May I know how you came to this number? > b) For the 5V -> 3.3V interface, xilinx application suggests a > Rser=300Ohm. Should I also replace this with a Rser=1kohm? The value is up to you: the choice is for speed, signal integrity, etc. Fast would be the smallest value, slower is a larger value. Peter's point is that if this is a slow interface (usually is), you don't need low resistance. > > 2)Why use a parralell resistor to the voltage regulator and waste power > to handle the reverse current. Why not just add a reverse biased > schotkey diode from the output to the input of the voltage regulator? We are not interested in protecting the regulator. What if the current forces the 2.5V Vcco and Vccaux to 5 volts? The the chip blows up...Article: 108538
The resistor value is a compromise between speed and current forced into the pin. The driver output impedance is probably below 10 Ohm. With a total load capacitance of 30 pF that creates an output time constant of 300 ps, pretty fast. With a 1 kilohm resistor directly attached to the FPGA pin, that pin has a capacitance of 10 pF. Times 1 kilohm that is a time constant of 10 ns, which is too slow in some cases, but probably fast enough in your case. And it limits the per-pin current forced into the FPGA to about 2 mA. The regulator usually cannot absorb current flowing backwards, so you must make sure that the current maintains its direction when the largest number of interfaces is High. When the current reverses direction, the voltage would rise, and might destroy the FPGA (unlikely, but possible). These are some of the nitty-gritty considerations that pay your (and my) salary... Peter Alfke =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D jidan1@hotmail.com wrote: > Thank you Austin and Peter for you replies. > > I still have 2 questions > > 1)a) So, you suggest using a 1k ohm serial resistor to interface the 5V > signal to 2.5V input. May I know how you came to this number? > b) For the 5V -> 3.3V interface, xilinx application suggests a > Rser=3D300Ohm. Should I also replace this with a Rser=3D1kohm? > > 2)Why use a parralell resistor to the voltage regulator and waste power > to handle the reverse current. Why not just add a reverse biased > schotkey diode from the output to the input of the voltage regulator? > > Austin Lesea schrieb: > > > jidan, > > > > Peter makes a good point: if the resistance is too low, then you are > > injecting current into the 2.5 V supply, and it may begin to drift up, > > and out of regulation. > > > > One way to avoid that, and to avoid any rail supply being driven above > > its intended output, is to balance the injected current with a simple > > resistor across the power supply, present all the time. > > > > So, if you think you will inject 100 mA worst case into the 2.5V rail, > > then plan on having a load of at least 100 mA on the 2.5 volt supply. > > If the 2.5 volt supply has a minimum normal load of 50 mA, then you will > > need an additional 50 mA load, just in case. 2.5V/.05=3D50 ohms (51 oh= ms, > > nearest 5% value). > > > > All this because regulators are good at regulating a load, but incapable > > of regulating when you source current into there output terminal. > > > > Austin > > > > Peter Alfke wrote: > > > jidan1@hotmail.com wrote: > > >> Hi, > > >> > > >> I would like to configure a spartan-3 FPGA with an 5V CMOS > > >> microcontroller. I have read xilinx database answer regarding how to > > >> make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm). > > >> > > >> 1) Can also the confg. dedicated pins made 5V tolerant through a ser= ial > > >> resistor although they are powered from 2.5V? (I calculated this an I > > >> came to Rser=3D220OHM) > > >> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is > > >> (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? If= yes, > > >> what IC's would you recommend? > > >> > > >> Regarding 1: > > > I would use 1 kilohm. No need to push more current than necessary. > > > Regarding 2: > > > You quote worst-case numbers that assum lowest Vcc on the FPGA and > > > higest possible Vcc on the uP. > > > Keep the FPGA fed with at least 3.2 V, and you will see that same > > > voltage on the output (this is CMOS !), and keep the uP Vcc slightly > > > below 5V. > > > But you will not have much noise immunity. > > > Peter Alfke > > >Article: 108539
David Ashley wrote: > Weng Tianxiang wrote: > > Hi Daniel, > > It is very interesting to learn there is a ring bus structure over > > there. > > Weng, > > It occured to me that your circuit was identical to the ring > buffer one. N users each had a fifo going to the DDR. > Then there was one stream coming out of the DDR, so > it's (N+1) interfaces. But then you said each user needs > its own fifo so it can store + forward data from the DDR. > So you've got 2N interfaces effectively. The new fifos are > just moved into the user's realm and not part of the DDR > controller. > > My point is the same circuitry exists in both cases. You've > just exercised some creative accounting :). > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture HI David, I am really surprised to what you recognized. They are totally different. This is ring topology: A --> B --> C --> D ^ -----------------------| This is my topoloty: A --> E --> | --> A B --> E --> | --> B C --> E --> | --> C D --> E --> | --> D WengArticle: 108540
jidan1@hotmail.com wrote: > Thank you Austin and Peter for you replies. > > I still have 2 questions > > 1)a) So, you suggest using a 1k ohm serial resistor to interface the 5V > signal to 2.5V input. May I know how you came to this number? > b) For the 5V -> 3.3V interface, xilinx application suggests a > Rser=300Ohm. Should I also replace this with a Rser=1kohm? Use the largest value that works, and you can also parallel a small C. That's what the universal programmers do, for wide pin voltage compliance, and keeps the edges fast enough to avoid problems. > > 2)Why use a parralell resistor to the voltage regulator and waste power > to handle the reverse current. Why not just add a reverse biased > schotkey diode from the output to the input of the voltage regulator? Or, you can use a DDR regulator : they are designed for source and sink. (if you expect a lot of unknown injection effects, tho worrying about mA in a Spartan-3 design is a little ?? ) -jgArticle: 108541
Jim, DDR regulator? I must have missed this new term. Do you have an example?| AsutinArticle: 108542
Weng Tianxiang wrote: >> Flexibility, scalability and routability are what makes ring buses so >> popular in modern large-scale, high-bandwidth ASICs and systems. It is >> all a matter of trading some up-front complexity and latency for >> long-term gain. >> >> Since high-speed parallel buses end up needing pipelining to meet >> high-speed timings, the complexity and area delta between multiple >> parallel buses and ring-bus topologies is shrinking. >> > > Hi Daniel, > It is very interesting to learn there is a ring bus structure over > there. > > "Flexibility, scalability and routability are what makes ring buses so > popular in modern large-scale, high-bandwidth ASICs and systems" > > Can you please me some reference papers about ring bus applications in > ASIC or FPGA? > > Normally what a designer is concerns most about is data latency in a > bus structure > Thank you. > > Weng Real-world ring-buses: - IBM Power4 Multi-Chip-Module core-to-core interconnect - IBM Power4 MCM-to-MCM interconnect - IBM Power4 system-to-system interconnect - ATI X1600/X1800 memory ring-bus IBM made lots of noise about its ring bus architecture a few years ago but I am pretty sure I read about something similar many years earlier. I am guessing Power5 must be using much of the same even though IBM did not make as much noise about it. -- Daniel Sauvageau moc.xortam@egavuasd Matrox Graphics Inc. 1155 St-Regis, Dorval, Qc, Canada 514-822-6000 From pcw@freeby.mesanet.com Tue Sep 12 15:48:44 2006 Path: newssvr29.news.prodigy.net!newsdbm05.news.prodigy.com!newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 12 Sep 2006 17:48:43 -0500 From: "Peter C. Wallace" <pcw@freeby.mesanet.com> Subject: Re: Spartan-3: 5V -> 2.5V level shifting Date: Tue, 12 Sep 2006 15:48:44 -0700 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: <pan.2006.09.12.22.48.39.297138@freeby.mesanet.com> Newsgroups: comp.arch.fpga References: <1158068790.190715.157620@p79g2000cwp.googlegroups.com> <1158072452.182351.246480@e3g2000cwe.googlegroups.com> <ee6jj6$ud2@cnn.xsj.xilinx.com> <1158094968.522912.30180@d34g2000cwd.googlegroups.com> <ee78ls$i5v1@cnn.xsj.xilinx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 40 NNTP-Posting-Host: 66.80.14.42 X-Trace: sv3-Zm7O9xpKMRFmRBHQzGTNHZXYBGLugyQq7cMr1F22FCSEChFODTq75rs37/zNWkno+MZi8dIEktviWwd!qaAHLcIrVsZJFIJXWBZdTdmoSyusFGBi1/zTl8KQrL4vjvVqGnymCKGyl2UG8/sq8XAUZsQwRMqp!FhTyLBEobZBkoZv53A== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: prodigy.net comp.arch.fpga:119434 On Tue, 12 Sep 2006 14:26:20 -0700, Austin Lesea wrote: > Answers below, > > Austin > > jidan1@hotmail.com wrote: >> Thank you Austin and Peter for you replies. >> >> I still have 2 questions >> >> 1)a) So, you suggest using a 1k ohm serial resistor to interface the 5V >> signal to 2.5V input. May I know how you came to this number? >> b) For the 5V -> 3.3V interface, xilinx application suggests a >> Rser=300Ohm. Should I also replace this with a Rser=1kohm? > > The value is up to you: the choice is for speed, signal integrity, etc. > Fast would be the smallest value, slower is a larger value. Peter's > point is that if this is a slow interface (usually is), you don't need > low resistance. > >> >> 2)Why use a parralell resistor to the voltage regulator and waste power >> to handle the reverse current. Why not just add a reverse biased >> schotkey diode from the output to the input of the voltage regulator? > > We are not interested in protecting the regulator. What if the current > forces the 2.5V Vcco and Vccaux to 5 volts? The the chip blows up... Another solution if you are worried about power consumption is a humble $.14 TL431 shunt regulator - good for up to 100 mA. We use this on some of our designs (on Spartan 2, making sure the the 3.3v rail doesnt get pulled up too high by 5V pullups on I/O pins) I'd set the TL431 for about 2.75V on the 2.5V rail... Peter WallaceArticle: 108543
Antti wrote: > a binary demo for Linux isnt much interesting or useful - everybody is > waiting when does PetaLogix finally release the PetaLinux, but so far > there has been to release date information announced by PetaLogix? Can > we assume that the actual PetaLinux release date is coming closer also, > or is PetaLogix still holding back information about possible release > date? Antti, a binary demo may not be useful to you, but it's obviously of some value to the people who've been asking for it, and the numerous people who've downloaded it in the just last 12 hours. One reason binary demos are valuable is for people who want a quick evaluation, a proof of concept, or even just be able to show their boss that indeed Linux on an FPGA works, and might make sense for their project. They don't want to take the time to learn how to build it themselves, they just want the "5 minute demo", and that's what this is about. One of the goals of PetaLinux, of course, is to enable people to build the 5-minute demo themselves, as well as provide an environment for major FPGA-based embedded Linux development. This is a lofty goal, which is why it's taking a while to get it developed and documented to a state where we are happy to release it. > I see the 'binary demo' is still based on EDK 8.1 tools - so it can not > fully support the MicroBlaze version 5, I wonder why hasnt PetaLogix > used EDK 8.2 tools? To what I know PetaLogix had early access to EDK > 8.2 (and GNU code?) and those would have been in the position to use > the latest GCC toolchain. Yes, we do have early access to the 8.2 tools, and indeed the current demo is based on 8.1. Why? Because as a small organisation operating out of a university research group we have limited resources which we must manage carefully. We also have paying clients who expect us to deliver what we have promised. If this means that PetaLinux, and other nice-to-have features that we will be giving aware free to the community (including you) must sometimes take a back-seat, then I can make no apologies for that fact. Regards, JohnArticle: 108544
karunesh.ind@gmail.com wrote: > i am preparing for intervew and i want the answer how Barrel shifter > can be used to optimize of C code at ARM processor. > > i have learnt that Barrel shifter is :A digital circuit that can shift > a data word by any number of bits in a single cycle. It is implemented > as a sequence of multiplexors: the output of one MUX is connected to > the input of the next MUX in a way that depends on the shift distance. > The number of multiplexors required is log2(n), where n is the > computer's register size. > Karunesh, In the interview, say exactly this: "It's how the compiler uses its ARMs. See, the barrel shape is perfect for hiding the application's private data. So the ARMs hold up the barrel. Shifting is done up or down as needed to improve performance." The position will be yours for the taking. NOTE: This is a joke. Don't do this in real life. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108545
I've just upgraded to 8.2 ISE and EDK and my project doesn't synthesize anymore. It complaints about not finding x_O,x _I, and x_T pins in the system module. Until now I used to instantiate system instead of system_stub in my ISE top-level design and thus avoided manual deleting of IOB instantiations. Now, Xilinx changed how they generate system.vhd and system_stub.vhd, so that my old method doesn't work anymore. What is the legal way of doing this? I edited system.vhd, but this doesn't seem to be enough and I hate the idea of needing to do it manually every time I change something in the system... The matter is further complicated by the fact that in some pcores (older ones I guess) bidir signals were declared in MPD with I, O, and T ports separately, so that one could easily make them separate external ports. In the newer cores (e.g. MPMC2) the ports are declared as IO in MPD, and I don't get it how to pass them up through the hierarchy cleanly... Really mad at all the time I've wasted installing the tools and now fixing my design. BTW, the only reason I installed 8.2 was because 8.1 crashed with the infamous portability errror, so I thought it was time to try the new version!!! Thanks, /MikhailArticle: 108546
"MM" <mbmsv@yahoo.com> wrote in message news:4moujqF7934gU1@individual.net... > I've just upgraded to 8.2 ISE and EDK and my project doesn't synthesize > anymore. It complaints about not finding x_O,x _I, and x_T pins in the > system module. Until now I used to instantiate system instead of > system_stub > in my ISE top-level design and thus avoided manual deleting of IOB > instantiations. Now, Xilinx changed how they generate system.vhd and > system_stub.vhd, so that my old method doesn't work anymore. What is the > legal way of doing this? I edited system.vhd, but this doesn't seem to be > enough and I hate the idea of needing to do it manually every time I > change > something in the system... The matter is further complicated by the fact > that in some pcores (older ones I guess) bidir signals were declared in > MPD > with I, O, and T ports separately, so that one could easily make them > separate external ports. In the newer cores (e.g. MPMC2) the ports are > declared as IO in MPD, and I don't get it how to pass them up through the > hierarchy cleanly... > > Really mad at all the time I've wasted installing the tools and now fixing > my design. BTW, the only reason I installed 8.2 was because 8.1 crashed > with > the infamous portability errror, so I thought it was time to try the new > version!!! > > > Thanks, > /Mikhail > > > This is interesting. This is exactly the opposite of what happened in my case. I could never get the 8.1 ISE/EDK to translate correctly until version 8.2. The process seems to be much simpler and controllable with 8.2 to me. DaveArticle: 108547
John_H wrote: > A 2-D example using fixed length SRLs that comes to my mind is a 90 degree > pixel rotation. > > If you have a 16x16 array of vectors that come in in the order > > A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 Aa Ab Ac Ad Ae Af > B0 B1 B2 B3 B4 ... > C0 C1 ... > . > . > . > P0 P1 P2 P3 ... > > And want to send them back out rotated 90 degrees so the order is > > A0 B0 C0 D0 E0 F0 G0 H0 I0 J0 K0 L0 M0 N0 O0 P0 > A1 B1 C1 D1 E1 ... > A2 B2 ... Just a nitpick but wouldn't this be a transpose? You'd need to invert in X or Y to get a 90 degree rotation. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108548
Weng Tianxiang wrote: > David Ashley wrote: > >>Weng Tianxiang wrote: >> >>>Hi Daniel, >>>It is very interesting to learn there is a ring bus structure over >>>there. >> >>Weng, >> >>It occured to me that your circuit was identical to the ring >>buffer one. N users each had a fifo going to the DDR. >>Then there was one stream coming out of the DDR, so >>it's (N+1) interfaces. But then you said each user needs >>its own fifo so it can store + forward data from the DDR. >>So you've got 2N interfaces effectively. The new fifos are >>just moved into the user's realm and not part of the DDR >>controller. >> >>My point is the same circuitry exists in both cases. You've >>just exercised some creative accounting :). >> >>-Dave >> >>-- >>David Ashley http://www.xdr.com/dash >>Embedded linux, device drivers, system architecture > > > HI David, > I am really surprised to what you recognized. > > They are totally different. > > This is ring topology: > > A --> B --> C --> D > ^ -----------------------| > > This is my topoloty: > > A --> E --> | --> A > B --> E --> | --> B > C --> E --> | --> C > D --> E --> | --> D > > Weng > Right, ok I didn't understand what ring topology was, sorry. Snip out my reference to ring topology then but my observation still goes. E is the DDR, right? Anyway you don't show the fifos associated with ABCD on the right side. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108549
Austin Lesea wrote: > Jim, > > DDR regulator? I must have missed this new term. > > Do you have an example?| Sure, Go to Linear or Maxim's web sites, and search for DDR regulator. These target the Vtt terminations on DDR memory busses, and they can source and sink current. -jg
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