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
(previously snipped question about high speed time measurements) Peter Alfke wrote: > Here are my thoughts for a fairly simple implementation. If I recall, the > original post asked for a report of the arrival time of input pulses (let's > assume rising edges) with a resolution of 1 ns. (snip) If I understand the way it is done in some experiments requiring sub nanosecond timing, they call it a TDC, time to digital converter, and it seems to work by generating a ramp signal, and digitizing it with a flash A/D converter at the trigger point. Maybe a 100MHz counter, and the sawtooth/ADC to get the low order bits. It might take some calibration, but numbers in the 100ps range seem to be easily obtained. 100MHz and a 6 bit ADC would give 10ns/64 or 156.25ps. -- glenArticle: 71776
> This code should work as far as I can tell. The statements where you > assign the count and trigger to themselves are not needed. I think you > may have included them for concern about generating latches if all cases > are not covered. But this only applies to combinatorial logic. You are > trying to infer sequential logic and so it is ok to have undefined > cases. The default is that the values are held if the conditions are > not defined (such as the else in the l_count=0 test). > > I suggest that you bring out all the signals to pins, including the > clock. Then probe it all with a scope to see if anything is working. > Also make sure that the pins you want are really being used. If nothing > seems to work, check back to the synthesis equations to make sure your > design is not being optimized away. > Hi Rick, thank you for your answer. I have looked at the synthesis equations and the RTL viewer to check the synthesis result. It seems everything to be OK. The PLL is running that is PLL input is running and PLL output clock is running as well. I have routet the PLL output clock (which feeds my small test design) to a debug pin. But the counter is not running. I have routet the bits of the 4bit counter to debug pins but there is nothing happening on those pins. My functional RESET is routet into the FPGA from a debug pin. It comes out from a watchdog. My counter is not resettet by that RESET. Could it be that the reset signal destroys configuration? But on the other hand that would mean that the PLL does not run. Or is a PLL handled separately? I do not know where to search. Maybe you have some idea. p.s. I am using Altera QuartusII software and Cyclone device. Kind regards AndréArticle: 71777
Ok, So I'm trying to convince myself that spending the $3000 on Foundation will be a good move, with one of the main reasons being that I won't have to constantly switch back and forth from Windows (to run Foundation, or WebPack currently) and Linux (to run everything else). I ordered (and eventually obtained - Xilinx *please* don't use DHL in the UK, it took 3 *hours* on the phone to re-arrange a missed delivery!) the evaluation pack, but this appears to only run on Windows, so it's essentially useless to me anyway - to be fair it did say it was Windows only, but I was hoping it would be the same package with a temporary licence. So, I'll consult the collective wisdom of the group - which is probably what I ought to have done in the first place :-) Can I ask if there's anyone who's used Foundation on both architectures... o If there are any differences between the two ? o Is there anything you can't do from the Linux environment ? o Is Linux a completely self-contained environment for development ? o How stable is it ? o What version of Linux are you running it on ? o Have you tried it on an AMD64 processor ? o Anything else I've missed ? (These being the main reasons I wanted to evaluate first...) Cheers, Simon.Article: 71778
Austin Lesea wrote:
Hi again (I confused the names Allan und Austin in my previous posting),
> Michael,
>
> I apologize if I seemed to imply that you were new at this.
>
> Series capacitors? Why? When you AC couple, now you have the
> impedance bump due to the layout from the caps, and their own ESL/ESR.
We had to manage different bias voltages for transmitter and receiver.
Thus we separated both by AC-coupling capacitors.
>
> Has anyone extracted the pcb layout and simulated the pcb traces using
> a 3D field solver? Have you looked at the impedance mismatch created
> by the series caps?
No, we didn't exctract and simulate pcb traces. But TDR measurement
showed an
impedance bump from 100 Ohms down to 80 Ohms diff. And behind the
AC-coupling
we saw app. 115 Ohms which represented the MGT receiver.
>
> Again, I strongly suggest getting to a RocektLab which is equipped to
> handle this. A quick call to a disti FAE (or even a Xilinx FAE) that
> has no real knowledge of your situation is not really going to get you
> the help you need.
We are in steady contact with Xilinx representative and FAEs. They have
been to our lab.
But there has not been any progress for a few weeks and no solution to
our problem !
That's why I turned to this forum and asked for assistance.
>
> Is there a case on this? Who is the CAE?
What means "case on this" and what is a CAE?
>
> Working with our Hotline is the best, fastest, and most effective way
> to solve any issue. This forum here is probably the worst from a
> time/accuracy/solution point of view for a specific customer issue.
> It is very useful to ping others in the community.
>
I'm sorry for the bad public relation. Xilinx claims to have thousands
of customers who
have boards at 3.125Gig working fine. But until this very moment, nobody
(even in this
forum) could tell me: "I truly measured a beautiful eye at my board's
MGT receiver! Here
is the screen shot..." Actually, can _SOMEONE_ give me such a
confirmation? Please!
The whole thing is weird and for my personal feeling quite nebulous!
_Austin_, sorry for my honesty! I hope you don't feel offended!
Regards.
Michael
> Austin
>
> Michael Mustermann wrote:
>
>> Hi Allan, hi Austin,
>>
>> thank you for you reply, but it won't help.
>> Of course, at MGT's speeds everything becomes just esoteric.
>> But we know this, we've designed serial gigabit board for several
>> years. We are familiar to single ended and differential impedance
>> and know how to lay out a board for these signals.
>>
>> We've carried out _true_ TDR measurement with Tek CSA8000
>> series scope which is able to send a positive and a negative pulse
>> exactly at the same time. Both the board and the MGT receiver
>> don't seem to be the issue, as I wrote earlier (see below).
>>
>> When I cut off the signal path by lifting the AC-coupling capacitors
>> 100mil before the MGT receiver and short the differential pair by
>> a simple 100 Ohms termination resistor, then I get wonderful waveform
>> and eye diagram!!! So it is proven, that I do not have a problem
>> along the traces, but together with MGT receiver.
>>
>> We use such links in the opposite direction as well, with the MGT as
>> the transmitter and a competitor's chip as the receiver. All other
>> details
>> are absolutely identical - same trace geometry, same connectors, same
>> distances - just different direction. Those links work _excellent_
>> and the
>> eyes look as pretty as in a schoolbook!!! So what do you thing?
>> Do I have a problem with my pcb???
>>
>> We have contacted the local FAE and he had no idea except the noise
>> at the MGT supply voltage. We were advised to measure at the
>> regulator and found app. 70mVpp noise. But even a lower noise supply
>> with 30mV hardly provided signal improvement.
>>
>> After 15" FR4 and two special high speed connector (AMP HM-Zd)
>> we get an 65mV eye opening at the MGT receiver package pin, but an
>> 650mV overall signal swing! App. 90% is degraded by reflections!
>> I could double the transmitter voltage swing, but I wonder, if this
>> is the
>> right approch...
>>
>> I'm out of ideas now.
>> Thank you for your assistance!
>>
>> Regards.
>>
>> Michael
>>
>>
>>
>>
>> Allan Herriman wrote:
>>
>>> On Fri, 23 Jul 2004 08:03:05 -0700, Austin Lesea <austin@xilinx.com>
>>> wrote:
>>>
>>>
>>>
>>>> Michael,
>>>>
>>>> At the speeds of the MGT signals, just about anything can be a
>>>> 'bump in the road', and cause reflections.
>>>>
>>>> No, the termination in the receiver is not perfect, (nothing is
>>>> perfect), but it is just fine regardless. Thousands of customers
>>>> have pcb's working at 3.125 Gbs error free, so it is more likely
>>>> that you have a pcb issue in your board.
>>>>
>>>> I suggest you immediately contact your local FAE, and arrange to go
>>>> visit one of our RocketLabs locations, where we have all of the
>>>> equipment to troubleshoot just such an issue, and the FAEs
>>>> associated with the RocketLab are all trained and familiar with the
>>>> equipment, and how to address the issues.
>>>>
>>>> One of the most common mistakes made in measuring the input
>>>> impedance, or return loss of the 100 ohm differential receiver, is
>>>> that they measure it single ended (50 ohm) and fail to take into
>>>> account that a differential return loss measurement is not a
>>>> trivial or simple thing to characterize accurately. For example,
>>>> two single ended 50 ohm traces are NOT 100 ohms differential (they
>>>> are less if they are routed together as they should be to be
>>>> differential). Bad mismatch right there!
>>>>
>>>> This goes for TDR as well. Unless it is a true differential TDR
>>>> measurement, you are not measuring what you need to measure (eg the
>>>> Tek CSA8000 is the only true differential TDR scope that I know of,
>>>> although I think Agilent now has one as well -- check! does it
>>>> send two impulses (or steps) at the same time of opposite
>>>> voltages? If not it isn't differential).
>>>>
>>>
>>>
>>>
>>> I've used an Agilent 54754A dual 18.4GHz TDR plugin in an 86100A scope
>>> for testing 10Gbps connections. I *think* it does a true differential
>>> measurement. [ I don't have the documentation handy. ]
>>>
>>>
>>>
>>>> As well, the time resolution fo the TDR may be much faster than the
>>>> rise time of the MGT signal, and may be showing issues that do not
>>>> affect the MGT operation (ie a mis-match at 20 GHz is not an issue,
>>>> as the signal has no energy at 20 GHz).
>>>>
>>>
>>>
>>>
>>> Yes, but better time resolution means better spatial resolution,
>>> allowing you to work out what went wrong with your board design.
>>>
>>> (I found this out the hard way.)
>>>
>>> Regards,
>>> Allan.
>>>
>>>
>> > > Hi anyone out there,
>> > >
>> > > we have designed a board with XILINX Virtex II Pro using the
>> > > RocketIO / MGT serial high speed transceivers.
>> > > Recently we experienced a problem with bit error rate (BER) and
>> > > measured the signal quality of the MGT serial links with a
>> 20Gsample
>> > > scope and 5GHz differential probe. We found a very poor signal
>> > > waveform and got an almost closed eye diagram.
>> > > We analyzed this phenomenon and now we assume, that the signal
>> > > degradation is caused by high reflections on the line. The
>> overshoot
>> > > and undershoot amounts to 50% of the singal swing. It seemed, that
>> > > the MGT receiver's input termination does not work properly.
>> > > Then we tried a TDR ("time domain reflectometer") measurement
>> > > to check the impedance characteristics of our board even into
>> > > the MGT's termination. The board traces are fine. Some impedance
>> > > mismatches are to be seen at vias, AC-coupling capacitors and the
>> > > Virtex II Pro package. But we think, these are not too bad, the
>> > > mismatch is in the range of 20%.
>> > >
>> > > Does anyone have experience with Virtex II Pro RocketIO?
>> > > Did anyone measure signal quality or eye diagrams on such a link?
>> > > May the impedance mismatches cause the high ringing we found?
>> > > Can anyone imagine the reason for the reflections though the signal
>> > > path's impedance seems to be not so bad?
>> > >
>> > > At the moment I don't have a clue.
>> > > Thank you for any hint!
>> > >
>> > > Michael
>> > >
>
Article: 71779Thanks for the help guys. I agree with Symon : it's a timing issue, functionality is 100% ok. And yes, it only happens when the carry out is the odd bit, not even. I also believe that the problem is MAP related, not XST (although I can not prove this). I tried with the "KEEP" attribute (which is XST equivalent of the synplify "syn_keep") : unfortunately this does not change anything. Also USE_CARRY_CHAIN and some other attributes I tried didnt do the trick. I was hoping there would be a clean and simple workaround, because I have a design with some 120 - 140 adders in it, I would hate to give up on readable code. But right now I would be happy with something that would work at all. If I do find some solution I will surely post it here. Bart. "Symon" <symon_brewer@hotmail.com> wrote in message news:<2mt4u2FqmqabU1@uni-berlin.de>... > Yeah, sorry Rick, I should clarify that when I said 'bad' I meant from a > timing point of view, not logic. I find that the tools rarely, if ever, make > logical errors these days. Maybe I'm just lucky? ;-) > cheers, Syms. > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:41095A10.6B315BF7@yahoo.com... > > > > That would be the problem the OP had. But the problem Symon described > > is a coding issue. But then he replied to my post and I may not have > > understood what he meant.Article: 71780
I would go with the serial line. However, keep it simple and don't use xmodem, write your own program. I do this also to download data to the FPGA for Flash programming. A very simple handshake with character echo from the FPGA relieves you from struggling with handshake and buffers in the FPGA (A PC can send up to 15 characters after you heave released CTS!) The donwload program is a 5 liner, you can find examples for the download program and flash programming on my website. Martin -- ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/ "Edmond Cote" <edmond_cote@yahoo.ca> schrieb im Newsbeitrag news:4109c1df_4@aeinews.... > > Hi, > > I'm currently trying to store non-voltatile data (32Mbits) in the flash > memory connected to an FPGA on a protoboard (Nuhorizon's spartan3 to be > specific), unfortunately I am not sure how to proceed. > > I'm thinking perhaps I could program the FPGA to pass the data from the > JTAG pins to the memory in either a serial or parallel manner, but for > the moment this is simply a hunch and wouldn't know how to go about > that. Can I simply send data via JTAG using Xilinx's iMPACT software?, I > suppose I could also xmodem the data via RS-232, what seems to be the > best method? > > If you've encountered this problem before, know of a better solution OR > (most importantly) could point me to relevent documentation, it would be > appreciated. > > Thanks, > > Ed > > > > > > > >Article: 71781
On 30 Jul 2004 03:17:08 -0700, zeeman_be@yahoo.com (Bart De Zwaef) wrote: >Thanks for the help guys. > >I agree with Symon : it's a timing issue, functionality is 100% ok. >And yes, it only happens when the carry out is the odd bit, not even. >I also believe that the problem is MAP related, not XST (although I >can not prove this). >I tried with the "KEEP" attribute (which is XST equivalent of the >synplify "syn_keep") : unfortunately this does not change anything. >Also USE_CARRY_CHAIN and some other attributes I tried didnt do the >trick. >I was hoping there would be a clean and simple workaround, because I >have a design with some 120 - 140 adders in it, I would hate to give >up on readable code. But right now I would be happy with something >that would work at all. You don't need to change a line of your HDL source. Write a (e.g. Perl) script to read the EDIF and locate the carry chains. From that you can generate a UCF which has an RPM for each carry chain. This will force MAP to do the right thing. Regards, Allan.Article: 71782
Rajeev wrote: > Lets take an example and see what the concensus is: > > Gate Count: 40K ASIC gates > Speed: 50 MHz > PinOut: 100 pins > Other: ??? > > > One Configuration: Spartan-III would be a suitable fit with $20 > price tag (scaling to $10 with volume) + $3 prom. > > Altenatives from Altera? Actel (may be anti fuse?) > > Could some one fill in... Where is the relation with my posting? MarioArticle: 71783
Thomas Reinemann <thomas.reinemann@masch-bau.uni-magdeburg.de> wrote: > against the background of partial reconfiguration, I would like to > determine the difference between two initial configurations (NCDs). Does > any Xilinx tool support this? You are probably looking for $ bitgen version1.ncd version1.bit $ bitgen -r version1.bit version2.ncd diff1to2.bit GerdArticle: 71784
I'm hoping someone out there can help me. We've been having lots of trouble closing the timing on our FPGAs with our bespoke vendor supplied static timing analysis tool. Is anyone out there using a stand alone static timing analysis tool (other than Primetime from Synopsys, or anything supplied by the FPGA vendors)? What is it? How do you find using it? What was the learning curve like?Article: 71785
Just wondering if anybody has a uLinux port for the Memec-Insight Virtex 2 pro 20 board ? Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 71786
Michael, Please email me directly with your contact information, FAE name, distribution FAE, etc. so I may escalate your case. By entering a case in the hotline, and communicating your expectations, we know how to address the issue, and we can track it. It is is not resolved quickly, we can escalate the issue to a team of experts. Not dealing with a customer case is a serious issue for the support staff, and is dealt with accordingly. Without a case number, and a contact, no one is taking the issue seriously, as it is not in the system as a "problem." FAEs may just consider this something that you may be 'playing' around with, and does not require their attention. I will personnaly find out why the field organization has not provided you with the answer, but without a case open, I can tell you right now that is a major factor! Visiting a RocketLab(tm), you could see many eye patterns on real boards. http://www.support.xilinx.com/products/xaw/hsd/simulator.htm Is the on line tool that has been checked to show that the simulated eye patterns are accurate, and represent the actual eye patterns on the thousands of combinations. I would suppose that others could send you their eye patterns, but that is up to them to decide to take the time and effort to do that. As well, posting graphics on this newsgroup is highly discouraged (as the graphics will be removed -- text only) so they would have to respond to you directly, and we do not know if the email address that appears in your posting is valid (many are not due to spam problems). My direct email is austin @ xilinx . com (without the spaces). One last comment, if the driver is also not 100 ohms matched, then any discontinuities upon reflection will re-reflect back to the receiver. There are some devices out there with very low, or very high transmit impedances (not ours) that have this problem. In any system or standard, the SI engineering makes assumptions. The assumption here is that both the Transmitter and the Receiver are to be as good a match as possible, so as to minimize the distortion to the eye pattern from 'normal' (that is, unavoidable)impedance discontinuities from vias, connectors, series AC blocking capacitors, package, and die variations. A simulation of an improper impedance transmitter will demonstrate this issue. (rant on) For all those who are reading this: do not let this happen to you! If you have an issue, get a case number! Follow the case progress on-line through our on-line tracking system. If at any poinht you feel progress is not satisfactory, ask to escalate the case (bumps it up the system to the next level of technical expertise). You are the customer: you are always right (by definition). We do not have a choice. If you ask, we must respond. And we do. (rant off) AustinArticle: 71787
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:OGnOc.50391$8_6.25426@attbi_s04... > If I understand the way it is done in some experiments requiring > sub nanosecond timing, they call it a TDC, time to digital converter, > and it seems to work by generating a ramp signal, and digitizing > it with a flash A/D converter at the trigger point. Maybe a 100MHz > counter, and the sawtooth/ADC to get the low order bits. It might > take some calibration, but numbers in the 100ps range seem to be > easily obtained. 100MHz and a 6 bit ADC would give > 10ns/64 or 156.25ps. > > -- glen In some TDCs, the ramp is generated by trigger signal and sampled by the steady clock. If the ramp came from the clock, you'd have large uncertainties near the corners; the harmonics to get a "nice" corner are also huge and outside the range of affordable A/D converters. By designing to guarantee a (reasonably) linear ramp, the trigger-signal's start ramp can be sampled in 2 spots on the ramp far from the "corner" giving the precise delta voltage for one sampling clock period. The stop ramp can also be sampled in 2 spots on the ramp and should have the same delta voltage. The voltage difference between these two ramp sample pairs relative to the voltage difference for one clock cycle will give you the offset in time relative to one clock cycle. But I hate precision analog beyond a few 10s of MHz. I prefer sinusoids. Generating a reference sine and cosine pair at a high frequency (say 200 MHz so nice A/Ds can be used), the two sinusoids can be sampled with a dual-channel A/D using the incoming signal as the trigger to get a sine/cos voltage pair. As long as the maximum amplitudes are measured or otherwise calibrated and the phase offset is close enough to 90 degrees (which can be calibrated downstream), the phase of the incoming signal comes straight from the arctan( sin/cos ) without ambiguity since the signs of the sine and cosine dictate the quadrant. The components to produce the clean sin/cos pair are widely available since many RF systems use I/Q modulation/demodulation or other "quadrature" techniques. With 10 bit A/D converters, the phase resolution is about 11 bits or about 2.5 ps resolution at 200 MHz; at this point the reference jitter and A/D aperture uncertainty will be major factors in the error budget. The incoming signal can transition as fast as the A/Ds can sample. It's a pretty system and FPGAs can do a great job with cartesian to polar conversion.Article: 71788
Over the last couple of weeks I have tried accessing the web site www.free-ip.com and gotten an error message. Am I the only one having this problem or are other people having this problem? Did something happen to this website? Is it mirrored someplace else on the web? Thanks, Derek SimmonsArticle: 71789
To all,
I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus
both within a BDF graph and also made my own configuration developed
using VHDL. They all work similarily but the concern is the
propagation delay which seems to be large (~ 7-10 ns). This limits
the total operation of the chip that I have to 100 MHz, which is a bit
strange? The chipset to which I synthesized too in Quartus is
EP1S10F780C6ES.
Can anyone tell me if this propagation delay is EXPECTED??? If so,
what is causing this FPGA speed limit? Can I reduce this somehow? I
anticipate to use this with my memory controller for PC100 SDRAM.
The configuration coded is as follows:
(not)OE
|
|
|\
| \
IN -------| /-------
|/ |
|----------Bidi-pin
/| |
OUT -------/ |-------
\ |
\|
|
|
OE
The functional VHDL code that I have implemented and simulated is as
follows:
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY Tristate_Buffer IS
PORT
(
OE : IN STD_LOGIC;
DATA_IN : IN STD_LOGIC;
DATA_OUT : OUT STD_LOGIC;
BUS_INOUT : INOUT STD_LOGIC
);
END Tristate_Buffer;
ARCHITECTURE mainRTL OF Tristate_Buffer IS
signal bus_wire1, bus_wire2 :STD_LOGIC;
BEGIN
op_assign_process: PROCESS (OE, DATA_IN, BUS_INOUT)
BEGIN
IF OE = '1' THEN
bus_wire1 <= DATA_IN;
bus_wire2 <= 'Z';
ELSE
bus_wire1 <= 'Z';
bus_wire2 <= BUS_INOUT;
END IF;
DATA_OUT <= bus_wire2;
END PROCESS op_assign_process;
bus_assign_process: PROCESS (bus_wire1)
BEGIN
BUS_INOUT <= bus_wire1;
END PROCESS bus_assign_process;
END mainRTL;
Article: 71790Hi I know how to define a personal type to use as a signal but how to use one as a port ? Sylvain MunautArticle: 71791
Derek Simmons wrote: > > Over the last couple of weeks I have tried accessing the web site > www.free-ip.com and gotten an error message. Am I the only one having > this problem or are other people having this problem? > > Did something happen to this website? > > Is it mirrored someplace else on the web? I am not able to connect either. The domain name is still registered. -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71792
Pino wrote: > > To all, > > I've discovered that there is some significant propagation delay > between the input and bidirectional pin & bidirectional pin to output > pin in my simulation. I've compared the function LPM_BUSTRI within > Quartus, a construction made up from Tri-state buffers within Quartus > both within a BDF graph and also made my own configuration developed > using VHDL. They all work similarily but the concern is the > propagation delay which seems to be large (~ 7-10 ns). This limits > the total operation of the chip that I have to 100 MHz, which is a bit > strange? The chipset to which I synthesized too in Quartus is > EP1S10F780C6ES. > > Can anyone tell me if this propagation delay is EXPECTED??? If so, > what is causing this FPGA speed limit? Can I reduce this somehow? I > anticipate to use this with my memory controller for PC100 SDRAM. > > The configuration coded is as follows: > (not)OE > | > | > |\ > | \ > IN -------| /------- > |/ | > |----------Bidi-pin > /| | > OUT -------/ |------- > \ | > \| > | > | > OE Altera supplies timing information in their data sheets, no? Why not look up the delays there? -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71793
> > I've discovered that there is some significant propagation delay >between the input and bidirectional pin & bidirectional pin to output >pin in my simulation. I've compared the function LPM_BUSTRI within >Quartus, a construction made up from Tri-state buffers within Quartus often prop delays in a tristate pin are due to OE performance - have you looked at the OE timinng numbers, or are you indeed looking at the prop delay of the in or out buffer. Most modern FPGAs now have syncronous OE and data registers at the pin, which can give you much better timing through the I/O. Mike Thomas Lattice faeArticle: 71794
Hello, I have created a modular design in VHDL which required 200 instances of the same module using the generate statement. I am designing for a Xilinx II FPGA and am trying to use the modular design flow. When I come to the Active Modular Implementation phase for the module that I implement 200 times I get NGDBuild error 560 saying that there are 200 active blocks (I assume that it is only expecting 1 active block). The options that I use with the NGDBuil command are -u, -uc and -modular module -active If anyone knows of any addition options I need to specify or even that I can't use the generate statement and have to create 200 separate modules then I would be very greatful for their help. Thanks very much, NickyArticle: 71795
Does anybody know of an fpga eval. board (preferably with a xilinx part) that has a spdif receiver on board(like the cirrus cs8414 or cs8416)? The higher fpga board seem to have stuff for video, but nothing for digital audio. Thanks, DaveArticle: 71796
Bart De Zwaef wrote:
> Hi all,
>
> I need some help here for implementing an efficient adder with carry
> out.
> Target : V2Pro
> System : WinXP, ISE 6.2.03 sp3
>
> I am trying to implement a 16 bit adder with carry out. I use the vhdl
> description for this as stated in the XST user guide (see src code
> added at the bottom of this post):
>
> q <= ('0'&a) + ('0'&b);
> where a and b are 16 bits, q is 17 bits.
>
> After PAR I see that the MSB of q (which is the carry out) is not
> using the carry chain, but uses local routing. SO : functionally it is
> OK, but timing is sub-optimal (about 250MHz in -5 V2Pro).
Hello Bart,
We've run your code and there is indeed a map packing problem. The MSB
is simply a FF driven by COUT of the previous slice. I see two related
problems with the packing:
1. FF "tmp1_16" should be packed into a slice utilizing the CIN pin
through the XORCY BEL as an extension of the carry chain but is not.
2. Instead, FF "tmp1_16" is being packed into the FFY BEL of the carry
chain slice that is driving it, displacing "tmp1_15" from its correct
packing location.
I've logged CR 192265 for these issues. Meanwhile, I don't see a work
around for first issue except to extend the carry chain by one bit as
you mentioned or possibly by instantiating an XORCY and FF to terminate
the carry chain. The second issue can be controlled with a map packing
constraint such as:
INST "tmp1_16" XBLKNM = XLNX_WA ;
I'll post again when we have a fix date scheduled.
Regards,
Bret Wade
Xilinx Product Applications
>
> When I implement a 17 bit adder with carry out (so 1 bit larger) :
> carry chain is OK, and we can get better timing (up to 290 MHz).
>
> I also tried the adder from CoreGen but the result is the same.
> Is there anyone who managed to make an adder with carry-out that uses
> the carry chain all the way, regardless of the width?
>
> Your help is much appreciated,
> Bart
>
> ---------------------------------------------------------------
> --
> -- File tstAdderCy.vhd
> -- Author BADZ
> --
> -- Target XC2VP20-5ff896 / XST ISE6.2.03i
> --
> -- Function : 16 bit adder with carry out
> --
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use IEEE.std_logic_unsigned.all;
>
> -- synopsys translate_off
> library unisim;
> use unisim.vcomponents.all;
> -- synopsys translate_on
>
>
> entity tstAdderCy is
> port (
> sClk : in std_logic;
> a : in std_logic_vector(15 downto 0);
> b : in std_logic_vector(15 downto 0);
> out1 : out std_logic_vector(16 downto 0)
> );
> end tstAdderCy;
>
> architecture arch of tstAdderCy is
>
> signal areg, breg : std_logic_vector(15 downto 0);
> signal areg2, breg2 : std_logic_vector(15 downto 0);
> signal tmp1 : std_logic_vector(16 downto 0);
>
> begin
>
> process(sClk)
> begin
> if rising_edge(sClk) then
> -- tck 1
> areg <= a;
> breg <= b;
> -- tck 2
> areg2 <= areg;
> breg2 <= breg;
> -- tck 3
> tmp1 <= ("0"&areg2) + ("0"&breg2); -- MSB of adder = last
> carry out bit, but MAP does NOT use dedicated carry-nets => not OK for
> timing
> -- tck4
> out1 <= tmp1;
> end if;
> end process;
> end arch;
> --------------------------------------------------------------
Article: 71797Wolfgang Denk <wd@denx.muc.de> wrote in message news:<I1Mv9s.953.3.diddl.denx@denx.muc.de>... > njoroge@stanford.edu (Nju Njoroge) writes: > > >I have been using the Riscwatch box w/ RISCwatch ver. 5.1 software. I > >am running Linux on our embedded PPC405D. The trace captures the > ... > >How can configure RISCwatch to access those interrupt address > >locations that need physical address? Anyone encountered this problem > >and found a way around it? I e-mailed IBM about it, but haven't gotten > >a response yet... > > The most common solution to this problem is to use an Abatron BDI2000 > instead... Thanks. I looked into this solution. While it does handle the translation while debugging, I'm looking to capture a trace output on file so I can do post-processing statistical analysis on it w/ gprof (i.e convert the trace output files into a gmon.out file). What I would like to know is if there is a command/mechanism within RISCWatch that could tell it for a certain address range not to access the TLB or turn off the TLB...This would help in the case of interrupts since Linux uses their physical addresses. RISCWatch seems to be passing these physical addresses to the TLB for translation, which is causing the errors I'm seeing. Perhaps I am asking too much from the tools :) > Best regards, > > Wolfgang DenkArticle: 71798
jg, My output is a clock which eventually will control A/D converter. Now, the clock for converter needs to have < 2ns Rise Time (For faster sampling rate, in my case 10MSamples/s) by the spec of it. Nobody really replied to my other question, can we generate clock on the Programmable Device (Max3032)? I want to generate 20MHz clock on the EPLD. Thanks, DrewArticle: 71799
Hello: I'm looking for the the data sheet on an Altera EPC2LC20. Can't find in on Altera web site. And a google search didn't uncover anything. It did direct me fo web pages but no data sheets for this device. Anyone got a copy? Thanks George
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