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
On May 4, 3:18=A0pm, Gabor <ga...@alacron.com> wrote: > On May 4, 2:29=A0am, Vips <thevipulsi...@gmail.com> wrote: > > > Hi All > > > What could be the optimal buffer for an asynchronous FIFO with the > > Write clock at 50 MHz and the Read clock is 25 MHz > > > Data is coming as 8 bits with each clock write . There is no idle > > cycle. We have to keep the synchronization latency also into account. > > > Thanks > > > Vips > > If I understand correctly you're asking how to calculate the > depth of the FIFO required for your application? =A0When you > say "there is no idle cycle" I assume you mean that data > is written to the input on every clock cycle. =A0For how long? > Obviously for this FIFO to work indefinitely, you would > need to adjust the output bandwidth to exceed the input > bandwidth or else its depth would need to be infinite. > > For a fixed input packet length you can calculate the depth > as the size of the packet minus the number of words read > from the FIFO while the packet was being written. =A0In > your case, assuming the FIFO read enable is always active > when the FIFO is not empty, there would only be a short > delay for flag synchronization, then one word read for > every two words written. =A0So the depth would need to > be half the packet size plus the number of input clock > cycles required to start up the readout. > > HTH, > Gabor Thanks Gabor I was also thinking the same. I was asked this question in an interview and wanted to know the answers from the experts. Though I also answered as infinite but the guy said there could be an "OPTIMAL" buffer to make sure there is no OVER RUN. When I asked him to answer and proof he simply declined. Anyways thanks .. regards VipulArticle: 147576
On May 4, 3:18=A0pm, Gabor <ga...@alacron.com> wrote: > On May 4, 2:29=A0am, Vips <thevipulsi...@gmail.com> wrote: > > > Hi All > > > What could be the optimal buffer for an asynchronous FIFO with the > > Write clock at 50 MHz and the Read clock is 25 MHz > > > Data is coming as 8 bits with each clock write . There is no idle > > cycle. We have to keep the synchronization latency also into account. > > > Thanks > > > Vips > > If I understand correctly you're asking how to calculate the > depth of the FIFO required for your application? =A0When you > say "there is no idle cycle" I assume you mean that data > is written to the input on every clock cycle. =A0For how long? > Obviously for this FIFO to work indefinitely, you would > need to adjust the output bandwidth to exceed the input > bandwidth or else its depth would need to be infinite. > > For a fixed input packet length you can calculate the depth > as the size of the packet minus the number of words read > from the FIFO while the packet was being written. =A0In > your case, assuming the FIFO read enable is always active > when the FIFO is not empty, there would only be a short > delay for flag synchronization, then one word read for > every two words written. =A0So the depth would need to > be half the packet size plus the number of input clock > cycles required to start up the readout. > > HTH, > Gabor Thanks Gabor I was also thinking the same. I was asked this question in an interview and wanted to know the answers from the experts. Though I also answered as infinite but the guy said there could be an "OPTIMAL" buffer to make sure there is no OVER RUN. When I asked him to answer and proof he simply declined. Anyways thanks .. regards VipulArticle: 147577
On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote: >I was also thinking the same. I was asked this question in an >interview and wanted to know the answers from the experts. Though I >also answered as infinite but the guy said there could be an "OPTIMAL" >buffer to make sure there is no OVER RUN. > >When I asked him to answer and proof he simply declined. That sounds like an employer you're better off not workiing for. If what you told us is an accurate reflection of the way the question was posed, it is evidence of sloppy thinking, poor use of language as a communication tool, and ambiguous specification. None of these are good attributes when you're trying to design products :-) It also sounds rather like an interviewer whose aim is not to select the best candidate, but to bully you into thinking that he's smarter than you. That sucks too. I've often heard people reporting the use of such FIFO-estimating questions in interviews. In every single case, the reported questions have been unanswerable unless you know the questioner's hidden assumptions. The result is that a truly smart candidate will have no choice but to ask a load of questions that the interviewer thinks are stupid, but in fact are just a reflection of the interviewer's poor communication. Great selection skills, eh? -- Jonathan BromleyArticle: 147578
On May 4, 3:18=A0pm, Vips <thevipulsi...@gmail.com> wrote: > > I was also thinking the same. I was asked this question in an > interview and wanted to know the answers from the experts. Though I > also answered as infinite but the guy said there could be an "OPTIMAL" > buffer to make sure there is no OVER RUN. > The minimal depth would be just large enough to cover the worst case latency in getting an item through the fifo so it would be roughly 2-3. Whether or not 'minimal =3D optimal' might depend on whether you have flip flops left over to implement the storage or internal memory blocks, but probably 'minimal =3D optimal' The width of the fifo would be double the width of the input data...in this case the fifo width would be 16 bits. > When I asked him to answer and proof he simply declined. > That will be left as an exercise to the reader...but presumably you now recognize that if you can pull data out in chunks that are twice as wide as the input, that it is now fairly straightforward to run the output side at half the speed of the input. Since this is stated as asynchronous clocks, one would also have to deal with whether or not the two clocks are independent or not. An input side that is running at 50.00001 MHz, would eventually overrun the output if it is running at 25.00000 MHz. To handle that situation, the output width just needs to be made wider...24 bits, 32 bits, depending very strongly on what the output side is connected to. Kevin JenningsArticle: 147579
On May 4, 5:19=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote: > > That sounds like an employer you're better off not workiing for. > If what you told us is an accurate reflection of the way the > question was posed, it is evidence of sloppy thinking, poor > use of language as a communication tool, and ambiguous > specification. =A0None of these are good attributes when > you're trying to design products :-) > Maybe, but finding a person that is able to deal with ambiguous specifications and still design a robust product might make for a good employee. If you can't design anything until you're told every last specification, you need to spend some more time thinking rather than waiting. The obvious solution in this case is simply to pull the data out at twice the data width as the input and be able to guarantee that the output clock frequency will be at least a wee bit greater than 2x the input clock frequency. If that guarantee cannot be met, then the output width must be larger (3x or 4x). > It also sounds rather like an interviewer whose aim is > not to select the best candidate, but to bully you into > thinking that he's smarter than you. =A0That sucks too. > Perhaps (and quite likely the case too)...but don't discount the chance that the interviewer was simply looking for someone who could notice that data widths are many times a design parameter that can be adjusted as necessary to meet the overall needs of the design. In this case, the input data width was specified (and somewhat irrelevant), but the output data width was left unconstrained and therefore open to whatever design considerations the interviewee might like to apply. > I've often heard people reporting the use of such > FIFO-estimating questions in interviews. =A0In every > single case, the reported questions have been > unanswerable unless you know the questioner's > hidden assumptions. =A0 You can also look at it as a chance to state your assumptions instead...don't ask if those assumptions are correct, simply state that since they weren't stated as design constraints you made the following assumptions and then lay out your design plan. > The result is that a truly > smart candidate will have no choice but to ask > a load of questions that the interviewer thinks > are stupid, but in fact are just a reflection of > the interviewer's poor communication. =A0 That's why you don't ask for the 'hidden assumptions', instead you state your assumptions and your solution. > Great selection skills, eh? You're probably right...but thought I'd give an opposing viewpoint. Kevin JenningsArticle: 147580
On Mon, 3 May 2010 23:27:57 -0700 (PDT), Vips <thevipulsinha@gmail.com> wrote: >Hi Guys > >What could be the optimal buffer for an asynchronous FIFO with the >source clock > >at 50 MHz and the Read clock is 25 MHz > > >Data is clming as 8 bits with each clock write . There is no idle >cycle. We have to keep the synchronization latancy also into account. If the frequencies are given without any accuracy, one can assume that they're phase locked (but unknown phase difference) with different frequencies. In that case there is a neat circuit trick which allows you to generate a sample clock guaranteed to be safe to sample incoming data with a single period latency of the fast clock. Then you can store one byte and on the second byte receive two bytes with your slow clock. In this case the fifo size is 1 byte and latency is 0 to 1 depending on which clock you use to decide. If on the other hand one interprets the async constraint as a very slow moving phase difference between the two clocks then the fifo needs to be arbitrarily large based on the number of bits delivered to the fifo vs number of bits read ie (50+ X ppm) MHz x 8 vs 25 MHz * 16. If the interviewer really meant no idle cycle with two actually async clocks, then you're better off at an other employer. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147581
On Tue, 4 May 2010 18:11:37 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >Since this is stated as asynchronous clocks, one would also have to >deal with whether or not the two clocks are independent or not. An >input side that is running at 50.00001 MHz, would eventually overrun >the output if it is running at 25.00000 MHz. To handle that >situation, the output width just needs to be made wider...24 bits, 32 >bits, depending very strongly on what the output side is connected to. When the "transmit clock" is faster this is indeed feasible, but what does one do when it is slower, ie 49.99999 MHz? Borrowing against future bits has not so nice consequences (as Greece is observing these days ;-) -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147582
Muzaffer Kal <kal@dspia.com> wrote: (snip) > If the frequencies are given without any accuracy, one can assume that > they're phase locked (but unknown phase difference) with different > frequencies. I suppose so, but in many real problems the accuracy is that of a crystal oscillator. One of my favorite examples comes from collision resolution in ethernet. The usual rule is to check to see if anyone else is transmitting before deciding to transmit. In case of a collision, each station stops sending, chooses a random number, and waits an appropriate amount of time based on that number. If another station is seen to transmit before your time is up, wait until that transmission is done and try again. The interesting one comes when transmitting after a collision. Because of possible variations in the clock (crystal), some stations will have a slightly faster clock. To avoid giving an advantage to those with a faster clock, there is a point at which one will transmit, even if a signal arrives from another station before transmission actually begins. The crystal variation goes into calculating that time. -- glenArticle: 147583
On 5/5/2010 11:24 AM, glen herrmannsfeldt wrote: > > The interesting one comes when transmitting after a collision. > Because of possible variations in the clock (crystal), some > stations will have a slightly faster clock. To avoid giving an > advantage to those with a faster clock, there is a point at which > one will transmit, even if a signal arrives from another station > before transmission actually begins. The crystal variation goes > into calculating that time. > That sounds like nonsense. I don't recall seeing that in the backoff algorithm for half duplex ethernet. Do you have a source to back up the apparently preposterous claim that users should deliberately force a collision? Thanks, Symon.Article: 147584
On May 5, 1:32=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Tue, 4 May 2010 18:11:37 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> > wrote: > > >Since this is stated as asynchronous clocks, one would also have to > >deal with whether or not the two clocks are independent or not. =A0An > >input side that is running at 50.00001 MHz, would eventually overrun > >the output if it is running at 25.00000 MHz. =A0To handle that > >situation, the output width just needs to be made wider...24 bits, 32 > >bits, depending very strongly on what the output side is connected to. > > When the "transmit clock" is faster this is indeed feasible, but what > does one do when it is slower, ie 49.99999 MHz? Borrowing against > future bits has not so nice consequences (as Greece is observing these > days ;-) > What borrowing are you talking about? If the transmit clock is less than 50 the fifo will simply have times when it is empty and no read would be performed on those cycles because the fifo flag said it has nothing in it. There was no stated requirement that there had to be reads on every clock cycle. Kevin JenningsArticle: 147585
On 5/4/2010 7:29 AM, Vips wrote: > Hi All > > What could be the optimal buffer for an asynchronous FIFO with the > Write clock at 50 MHz and the Read clock is 25 MHz > > > Data is coming as 8 bits with each clock write . There is no idle > cycle. We have to keep the synchronization latency also into account. > > > Thanks > > Vips You could have the read side running at 87% of light speed. Then, special relativity time dilation effects mean that you will have enough time to get the data out with a 25MHz clock, for an observer traveling with the read side. Was the job at CERN? HTH., Syms.Article: 147586
On 5/4/2010 2:19 PM, Jonathan Bromley wrote: > On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote: > >> I was also thinking the same. I was asked this question in an >> interview and wanted to know the answers from the experts. Though I >> also answered as infinite but the guy said there could be an "OPTIMAL" >> buffer to make sure there is no OVER RUN. >> >> When I asked him to answer and proof he simply declined. > > That sounds like an employer you're better off not workiing for. > If what you told us is an accurate reflection of the way the > question was posed, it is evidence of sloppy thinking, poor > use of language as a communication tool, and ambiguous > specification. None of these are good attributes when > you're trying to design products :-) <snip> >The result is that a truly > smart candidate will have no choice but to ask > a load of questions that the interviewer thinks > are stupid, but in fact are just a reflection of > the interviewer's poor communication. Great > selection skills, eh? When interviewing candidates, I almost always ask an impossible question or two. It is a test of character, not of knowledge. I don't want someone who just gives up, nor do I want one who guesses at the missing information. I want someone who is not afraid to question authority until he is sure he can solve the problem correctly. Very little in many interviews is as it seems. CurtArticle: 147587
I have written a custom SOPC builder component in VHDL. Right now I have SOPC builder auto-generating a package that contains custom type definitions that are used throughout my custom SOPC builder component. These type definitions are based on the settings input by the user in the SOPC builder GUI. This package is then included in each of the VHDL files of my custom component using the construct: library work; use work.custom_package.all; Now, the problem with this formulation is that I can only have one instance of the component in my sopc system. Does anyone have a workaround for this, where I can generate multiple unique package files, each one associated with a particular instantiation of my custom VHDL component? In a perfect world, I might be able to use VHDL 2008 constructs which allow for passing custom types as generic parameters on a component. Quartus and SOPC do not support this. Another intractable solution would be to remove all the custom types which are used all throughout my custom component and use generic parameters and std_logic_vectors types all the way through the project. At this point the component is too complex to try and remove all of the custom types and replace them with standard types (whose bitwidths, etc would be set via generics). A third undesirable workaround would involve auto-generating every single VHDL file used in my component and passing the name-decorated version of my custom package to a VHDL generation script which could then generate a customized, name-decorated version of each VHDL file needed for my component. This is kind of a nasty and inelegant way of doing what I want. What I would like to be able to do is have two instances of my custom component in my sopc system. Let's call them Custom1 and Custom2. My custom_component_hw.tcl script could then generate two unique VHDL packages associated with each instantiation. It would generate Custom1_Package.vhd and Custom2_Package.vhd. Is there a way to associate Custom1_Package.vhd with one instance of all of my custom VHDL source files and associate Custom2_Package.vhd with a second instance of them. I would prefer to not have to write a complex code generator script to allow for this.Article: 147588
Hi to all,
I am the begginer in microblaze. I want to just print the value of
the float variable "fpu" (=2.345) on the uart. can you please tell me how
to write it in the microblaze (C), Can you tell me right from the include
statements, because I not even know what are the header files it usesw to
include floating point unit. I have just added FPU in the BSB launcher when
the EDK invokes. I dont know what should i do later. Plz help me
Thanks
Bhaskar
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 147589Hello, My design is an spartan 3 with MicroBlaze. I'm running functional simulation in NCsim ( CADENCE ). Does anyone knows how to intergrate an rtl model of the microblaze in the functional simulation? I found some .vhd files but they are all encrypted. Xilinx did not givve me answer about that yet. Does anyone knows about an rtl model for Microblaze of a similar processor? Lior --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147590
Is there a way to get SignalTap to display just the signal name without the entire path? If the signal is deep within the hierarchy it's completely unreadable.Article: 147591
On Wed, 05 May 2010 17:28:05 +0000, General Schvantzkoph wrote: > Is there a way to get SignalTap to display just the signal name without > the entire path? If the signal is deep within the hierarchy it's > completely unreadable. BTW it's the Beta version that seems to have the problem, the old version supports right alignment and Alias which doesn't seem to work in the new version. The new version uses a Linux native toolkit rather the the horrible Windows emulator that the old version uses. The old version is unstable when running over ssh, the new version is fine. More importantly the remote performance (I'm accessing a system over the Internet) is orders of magnitude better with the new version.Article: 147592
Symon <symon_brewer@hotmail.com> wrote: (snip on ethernet collision resolution) > That sounds like nonsense. I don't recall seeing that in the backoff > algorithm for half duplex ethernet. Do you have a source to back up the > apparently preposterous claim that users should deliberately force a > collision? Not deliberately force, but if two stations compute the same backoff delay, proper resolution requires that the collision occur. That is true, even if the signal from one arrives at the other before the latter starts sending. I will have to see about a reference. -- glenArticle: 147593
Symon <symon_brewer@hotmail.com> wrote: >> The interesting one comes when transmitting after a collision. >> Because of possible variations in the clock (crystal), some >> stations will have a slightly faster clock. To avoid giving an >> advantage to those with a faster clock, there is a point at which >> one will transmit, even if a signal arrives from another station >> before transmission actually begins. The crystal variation goes >> into calculating that time. > That sounds like nonsense. I don't recall seeing that in the backoff > algorithm for half duplex ethernet. Do you have a source to back up the > apparently preposterous claim that users should deliberately force a > collision? Actually, I believe the one I was thinking about is in the inter-frame gap algorithm. In both the IFG and collision resolution case it is required that when stations are scheduled to send that they actually do so. If carrier sense is active, a station waits until it goes inactive, waits the appropriate IFG delay, and transmits. There is a point during the inter-frame gap time that the station makes an irrevocable decision to transmit, even if carrier sense goes active. That is necessary for fair access to the medium within the tolerance of the crystal oscillators, and other possible delays. Also, the RS232 asynchronous communication stop bit is needed to allow for possible clock differences between two stations. -- glenArticle: 147594
Hi, you can generate simulation model of your system from the XPS GUI. I don't remember the exact process but it is (was) well documented. XPS also generates script files for modelsim to setup and run a simulation. I managed to run it in activeHDL after downloading some precompiled libs for microblaze from aldec' site. Remember that if you have external components (e.g. SDRAM) you most likely need sim models of those too to make any sensible simulation runs. Finally, if you intend to verify a custom peripheral you might consider doing a BFM sim instead. You will then need to get the PLB toolkit from xilinx. HTH MagneArticle: 147595
I am working on bit of a complex DSP design and generating .vhdl files based on the MATLAB/Simulink design. These vhdl files are then imported into a Xilinx project file and mapped, placed, routed, testing for timing to eventually generate a bit file for a Virtex SX95T. When I get a failed timing constraint, I manually place slices or add latency to meet timing. I succeed in fixing this failed timing constraint but get a new one in a unrelated block. My question is if this new timing constraint is a side effect of my change or if Xilinx does sequential failed timing error reporting ? I'm running Xilinx ISE 10.1.03 Foundation and the appropriate sysgen. Regards, SharmilaArticle: 147596
On 5/5/2010 10:03 PM, glen herrmannsfeldt wrote: > Symon<symon_brewer@hotmail.com> wrote: > >>> The interesting one comes when transmitting after a collision. >>> Because of possible variations in the clock (crystal), some >>> stations will have a slightly faster clock. To avoid giving an >>> advantage to those with a faster clock, there is a point at which >>> one will transmit, even if a signal arrives from another station >>> before transmission actually begins. The crystal variation goes >>> into calculating that time. > >> That sounds like nonsense. I don't recall seeing that in the backoff >> algorithm for half duplex ethernet. Do you have a source to back up the >> apparently preposterous claim that users should deliberately force a >> collision? > > Actually, I believe the one I was thinking about is in the inter-frame > gap algorithm. In both the IFG and collision resolution case it > is required that when stations are scheduled to send that they > actually do so. If carrier sense is active, a station waits until > it goes inactive, waits the appropriate IFG delay, and transmits. > There is a point during the inter-frame gap time that the station > makes an irrevocable decision to transmit, even if carrier sense > goes active. That is necessary for fair access to the medium > within the tolerance of the crystal oscillators, and other possible > delays. > > Also, the RS232 asynchronous communication stop bit is needed > to allow for possible clock differences between two stations. > > -- glen Dear Glen, Thanks for the clarification. I wonder, could you point me to a 'inter-frame gap algorithm' specification which proposes that a user should send despite the channel being busy? Also, I am interested in your concluding statement about RS232 stop bits. I gather you live in a world of half-duplex. How would you propose to eradicate the stop bit in a world where we are all synchronised? How would we synchronise ourselves? Would we need to be adjacent? Thanks, Syms.Article: 147597
On May 5, 7:38=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 5/5/2010 10:03 PM, glen herrmannsfeldt wrote:
> > Also, the RS232 asynchronous communication stop bit is needed
> > to allow for possible clock differences between two stations.
>
> Also, I am interested in your concluding statement about RS232 stop
> bits. I gather you live in a world of half-duplex.
>
> How would you propose to eradicate the stop bit in a world where we are
> all synchronised?
>
> How would we synchronise ourselves?
>
> Would we need to be adjacent?
First of all, I'm never sure exactly how serious some of your
questions are. Especially on the latter two questions, I'm not sure
exactly where your tongue is. But on the off-chance that it's not
firmly planted in your cheek, I will endeavor to answer some of these
questions.
In asynchronous serial communications, the start and stop bit happen
even in full duplex communication -- they have nothing to do with half
duplex. Turn-around in half-duplex modems is a much more cumbersome,
time-consuming event than a single bit time will allow for. That's
what the RTS and CTS signals are for ("Request to send" and "Clear to
send", as in "I want to talk" and "OK, nobody else is talking, I fired
up our carrier and it's been long enough the other side should have
locked to it, so you can start sending bits.")
But async itself is a very simplistic scheme. The only "locking" of
the source and destination clocks happens based on the leading edge of
the start bit. Assuming the simple case of 8N1 (8 bits, no parity,
one stop bit), ten bits are transmitted for every 8 bits. That may
sound like 8b/10b, but trust me, it's not! There is no DC balance, no
guaranteed transitions, no out of band framing indicators, none of
that fancy stuff.
The worst case for RS232 is recovering the 0x00 character, which at
8N1 will be 9 low bits followed by a high bit. If the receiver clock
is too fast, it might think there is a missing stop bit ("framing
error" or "break") If the receiver clock is too slow, it might think
that what was transmitted was a 0x80 (think the stop bit was the last
data bit).
After receiving the leading edge of the start bit, you use "dead
reckoning" to try to sample in the midpoint of every bit. You hope
that the delta between your clock and the source clock is not too
much, and that the cable is not so long that pre-charge distorted the
first bit a lot, and that the interminably long slew rate is
symmetrical around your receiver's transition point. A quick back of
the envelope calculation shows that for 8N1, you could support a
receive/ transmit clock delta of approximately 5% if there were no
start bit distortion and no slew asymmetry. Many typical RS232
circuits (ab)use this tolerance to transmit or receive a percent or
two off the nominal frequency.
There are lots of ways to get rid of the need for a start and stop bit
short of using full-blown 8b/10b. Bisync is an ancient one; SDLC/HDLC
is merely old. Both of these technologies send packets of bytes at a
time, usually with a CRC for error correction, whereas async is
perfectly happy to send a single byte, and is often used for short
hauls with no error detection or correction.
BTW, because async is so simple, the UART is usually given as a task
to the intern. Guess which block often comes back with lots of corner
case errors?
Regards,
Pat
Article: 147598On May 5, 5:47=A0pm, Sharmila <sharmi...@gmail.com> wrote: > I am working on bit of a complex DSP design and generating .vhdl files > based on the MATLAB/Simulink design. These vhdl files are then > imported into a Xilinx project file and mapped, placed, routed, > testing for timing to eventually generate a bit file for a Virtex > SX95T. When I get a failed timing constraint, I manually place slices > or add latency to meet timing. > I succeed in fixing this failed timing constraint but get a new one in > a unrelated block. My question is if this new timing constraint is a > side effect of my change or if Xilinx does sequential failed timing > error reporting ? > I'm running Xilinx ISE 10.1.03 Foundation and the appropriate sysgen. > Regards, > Sharmila Under the properties tab for the post-PAR timing analysis, you can tell it how many paths per clock you want to see. I think the default is only 3. You can also ask it to perform "advanced analysis" and tell it you want a "verbose report" and get information on paths that pass, but are marginal. But the whole thing is kind of like a balloon animal -- press over here, and it will pop out over there. That certainly could be happening to you. Regards, PatArticle: 147599
Hi, Does someone have some benchmarks comparing the compilation time between the Windows 64b and Linux 64b editions of the Xilinx ISE Design Suite? I need some arguments to invest in the right development platform. Many thanks. Eric
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