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
Ed McGettigan wrote: > jason.stubbs wrote: > >> Ed, >> >> So, if I send data from a V2Pro to a V4 the MSB is sent first. when >> the V4 receives and deserializes the data, the MSB of the V2pro becomes >> the LSB of the V4? >> >> And if I send data from a V4 to a V2Pro the LSB is sent first. when >> the V2Pro receives and deserializes the data, the LSB of the V4 becomes >> the MSB of the V2Pro? >> >> If the bus order is inverted at one end of the link, everything should >> be OK? >> >> Jason >> > > No, it's a byte ordering issue, not a bit ordering issue, so > the order that the bytes are sent or received are different. > > V-II Pro V-II Pro X/V-4 > 1 Byte: [7:0] = [7:0] > 2 Byte: [15:8][7:0] = [7:0][15:8] > 4 Byte: [31:24][23:16][15:8][7:0] = [7:0][15:8][23:16][31:24] > > For example if you want to send the following bytes in the > following order: > > Byte 1 = 0xDE > Byte 2 = 0xAD > Byte 3 = 0xBE > Byte 4 = 0xEF > > In Virtex-II Pro TX/RXDATA[31:0] would be 0xDE_AD_BE_EF > In Virtex-II Pro X TX/RXDATA[31:0] would be 0xEF_BE_AD_BE > In Virtex-4 TX/RXDATA[31:0] would be 0xEF_BE_AD_BE > > Ed > One caveat with the above is that this is true for the encoded modes. In the case of non encoded (aka raw) bit ordering would be a complete LSB to MSB swap. EdArticle: 82601
I investigated further and was able to get 3v across the switch by isolating the TTL side of the switch from the rest of the bus and driving the switch with a signal generator. And for some reason now, with everything as it was, I do see 3v on the virtex2 side of the switch, even though I know at one point I did not. So I will continue investigating based on the assumption that something on the TTL bus is loading the bus down when performing a read from the virtex2 device. Austin, thanks again for letting me know that what I was seeing was abnormal, and that I should relook at it. gja "gja" <geeja@hotmail.com> wrote in message news:F2j7e.211$V02.115@fe08.lga... > Austin, thank you for your responses. My replies are below: > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:d3k3jm$mav1@cliff.xsj.xilinx.com... > > gja, > > > > See below, > > > > Austin > > > > gja wrote: > >> Austin, are you saying that you've actually seen the circuit actually > >> pass 3v across the switch ? > > Yes, I have. > > OK, I will have to investigate further now that I know that it should. > > > > Or are you saying that the output SHOULD be clamped > >> around 2.3v ? > > No, I am not. > >> > >> Perhaps I should've been more clear, but I am currently testing a new ckt > >> board built with the circuit in xapp646 and a virtex2 part. > >> With the IDT vcc at 3.3v, the maximum voltage I am seeing with a scope > >> is about 2.3v on the output side of the switch. IE., when the virtex2 > >> part is driving (lvttl) one side of the switch at 3.3v, the other side of > >> the switch is about 2.3v. > > Into what load? On a "real" PCI bus is where I made the measurements. > > Perhaps if you use the resistor "standard termionation" (which is anything > > but a standard) you will get some other result? > > My application uses the switch to connect a Virtex2 to a slow (1us access > times) 5v TTL databus, not PCI. The virtex2 pins are configured as lvcmos33 > iobuf and is the only device on one side of the quickswitch, so I don't > think it is a loading problem. When the 5v FCT chip is driving the virtex2 > (thru the switch), I see 4v on the ttl side but only 2.3v on the virtex2 > side. > > > When the 5v ttl part 74FCT645 is writing to the virtex2 part, > >> I see 4v on that side of the switch and 2.3v on the virtex2 side. > > OK. I will admit that the TI part has some advantages, but it is also an > > active device, and adds delay, doesn't it? > > No, the TI devices SN74CB3T3384 and SN74CBTD3384C are also FET switches > with the same delay spec as the IDT part. The SN74CB3T3384 device uses a > vcc of 3.3v while the SN74CBTD3384C uses 5v. Both devices claim to do 5v to > 3.3 v level translation. > > > When I > >> originally looked at xapp646, it stated that it would clamp to less than > >> ~3v outputs, I didn't think it would be closer to 2.3v. If I had used > >> the implementation in IDT's or TI's appnote where they drive the vcc pin > >> at 4.3v using a diode from 5v, I wonder if that would have worked better. > > Except that then you do not limit the voltages to less than what we > > require. > > They do because the QS3861 clamps to VCC-1, so 4.3 - 1 = 3.3v > > >Article: 82602
Ed, No offence taken Ed! Especially as you agree that switching regulators can work later on in your post. I did write "as long as you provide for adequate filtering on the supplies". I realise that you guys write your App. notes to protect your customers from when designs go bad, and you err on the side of safety, but all I'm trying to say is that it can work. I accept it may be a more risky route. Some ways to reduce the risk are:- 1) Defeat any burst mode the switcher may have. The bursts can give bad LF noise. 2) Provide for resistive low frequency filtering. 3) Switch as fast as possible, some modern switchers switch at several MHz, easier to filter. 4) Don't skimp on the layout effort and bypassing. 5) Don't use a board wide supply plane. I wonder if you see mostly bad switcher designs because no-one rings Xilinx to complain when the switcher design works! Cheers, Syms. "Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message news:425EAEE6.3020708@xilinx.com... > Symon please don't take any offense at this, but this information > is wrong and would like lead a designer into a serious issue with > their high speed serial links if they were to take your advice. > > For the record, Xilinx design requirements for the RocketIO supplies > are that the supply is sourced from a linear regulator with capacitive > filtering as noted in the RocketIO user guides. In addition each > RocketIO voltage is to be isolated from the supply with a ferrite bead. > > Depending upon the family and package type you may also need another > cap on the FPGA side of the ferrite bead as noted in the RocketIO user > guides. > > Yes, you can have one supply to be the source for all RocketIO and you > do not need to have individual regulators for each RocketIO or for > each supply type. > > We make these requirements for your benefit and link quality across all > possible conditions. > > In the real world, I have seen a few cases where switching power > supplies have worked. I have also seen far more cases where they > are the root of the problem in a totally dead link or have produced > a marginal link. > > Ed >Article: 82603
Rudolf Usselmann <russelmann@hotmail.com> writes:
> I read your post and did try the things you suggest, but like
> you, I too was NOT successful, installing the 64 bit version of
> ISE 7.1.
Sorry, I didn't read your post carefully enough so I didn't realize
that you were trying to use the 64 bit version. I've been happy with
the 32 bit version.
If I had the full ISE rather than BaseX, and wanted to run the 64-bit
version, I'd probably install Centos Linux 3.4 (community-maintained
derivative of RHEL 3):
http://www.centos.org/
Eric
Article: 82604Ed McGettigan <ed.mcgettigan@xilinx.com> writes: > For the record, Xilinx design requirements for the RocketIO supplies > are that the supply is sourced from a linear regulator with capacitive > filtering as noted in the RocketIO user guides. In addition each > RocketIO voltage is to be isolated from the supply with a ferrite bead. [...] > In the real world, I have seen a few cases where switching power > supplies have worked. I have also seen far more cases where they > are the root of the problem in a totally dead link or have produced > a marginal link. If I used a linear regulator, it would be fed from a higher voltage from a switcher. I've observed that linear regulators provide almost no filtering of the switching noise, because their frequency response doesn't extend that high, so apparently the recommended capacitive filtering takes care of that? If so, why doesn't the capacitive filtering work adequately when using just a switcher? Thanks, EricArticle: 82605
gja, No problem. Good luck with your troubleshooting. AustinArticle: 82606
:
You will probably be OK. The mapper tends to put one lut/ff per slice
when there is lots of room in the device. Note that your total slice
count for the individual designs is a bit less than the slice count in
the device, so even without sharing slices you'll fit. A better
indicator is the LUT and FF counts, but with the caution that depending
on the design you may not be able to pack some of them in the same
slice. In your case, I don't see a problem.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 82607ok I wasnt lazy the freelib1 is now downloadable http://gforge.openchip.org/projects/wwwfreeipcom/ antti "Daniel Florin" <florin@primelec.ch> schrieb im Newsbeitrag news:d3ma49$pm4$1@news.hispeed.ch... > Over the last couple of weeks I have tried accessing the web site > www.free-ip.com and gotten an error message. Is it mirrored someplace else > on the web? > > I am looking for Free-LIB1, a library of NCO, DAC and PWM parameterized > cores in VHDL, which was available at www.free-ip.com. > > Any information is very appreciated. > >Article: 82608
On Thu, 14 Apr 2005 13:25:20 +0200, Engineering Guy <whataloginsfor@os.pl> wrote: >Reinier wrote: > >> Hi, >> >> I'm looking for a freeware or low cost program do document and >> illustrate the signal processing flow in my FPGA design. I'd like to >> use building blocks like adders, multipliers, memory, busses etc. What >> do you guys use to make some nice looking pictures? I don't want to >> spend days learning Corel Draw or something huge like that. >> >> Thanks, >> Reinier > >Never used, but heard of Dia: > http://www.gnome.org/projects/dia/ >It is claimed to be a Visio replacement. Its multi-platform and free. >Give it a try. > >EG Thanks, I'll give it a try. BTW, I found an ancient Win95/NT program (Flow!) in the office that was just collecting dust. Thanks for your input! ReinierArticle: 82609
Eric, I wonder if it's because of low frequency noise generated from switchers that are working in burst mode? The subsequent linear regulator can deal with that. Cheers, Syms. "Eric Smith" <eric@brouhaha.com> wrote in message news:qh1x9d17jw.fsf@ruckus.brouhaha.com... > If I used a linear regulator, it would be fed from a higher voltage from > a switcher. I've observed that linear regulators provide almost no > filtering of the switching noise, because their frequency response > doesn't extend that high, so apparently the recommended capacitive > filtering takes care of that? If so, why doesn't the capacitive > filtering work adequately when using just a switcher? > > Thanks, > EricArticle: 82610
Austin, hello Thank you for your reply. I have visited the site you mentioned but failed to find an LVDS card with a pci interface. I have noticed that you are a Xlinx member, could you point other companies that implement LVDS on your FPGAS? Thanks in advance, and sorry to bother you, Marc.Article: 82611
Hallo, I should connect the wishbone can core with opb bus. I have downloaded from asics.ws the wrapper. There is someone who could explain how to use it? I have also made some search for a tutorial or documentation, but I don't have found nothing. Where I could find the documentation? Many Thans Marco Thanks Marco ToschiArticle: 82612
Greetings,
Comments inline below...
C. Peter (die_les_ich_nicht@gmx.net) wrote:
: Hi all,
: some years have gone since I did something with FPGAs and I am aware that
: technology has moved forward significantly since the end of the last
: century ...
: We now think about reading out some CCD sensors and doing image processing
: with an FPGA. My questions to you:
When you say "reading out some CCD..." does this include generating the
various readout waveforms for the CCD? FPGAs make excelent waveform
generators for controling a CCD, and can be much better suited to
this task than a CPU, although care is needed with the timings.
So yes an FPGA is good for readout control, but whether it is good for
image processing depends on the nature of the processing. If you ask
yourself "are my processing algorithms highly deterministic?" and the
answer is "yes", then the FPGA is likely a good choice. If the answer is
"actually no, our reference C code is full of conditional branches and
uses different algorithms bassed on the image content etc." then more
consideraton is needed.
Cheers,
Chris
: - do you think this is feasable?
: - which FPGA would you recommend?
: - Which language would you recommend?
: We have used Xilinx and Handel-C so far and hence would prefer to stick to
: them. But if there are good arguments against it we would certainly follow
: them.
: Thanks a lot for your advice,
: Christian
Article: 82613On 13 Apr 2005 09:12:51 -0700, "Andy Peters" <Bassman59a@yahoo.com> wrote: >I'm sure others have this problem ... > >Is there a tool that'll let one view and hopefully print a schematic >done in the old Xilinx F2.1i schematic tool? The new stuff doesn't >want to know about the old stuff, and worse is that you can't even >install 2.1i on an XP machine. (Yeah, that'll teach me to upgrade.) > >I don't want to do anything with this schematic other than view it. >I'm doing a new board sorta based on an old design, and the new design >will of course be in VHDL rather than as a schematic. > >Ideas? > >-a What the world needs is a standard schematic file format. Our policy now is to release PDFs of all schematics with the designs, so at least it's easy to see what's there. JohnArticle: 82614
"Jerry" <nospam@nowhere.com> wrote in message news:n9l7e.9709$_63.1095@fe03.lga... > I download my design via byteblaster USB. The leds wink and blink as if the > fpga is taking the data. > At the end of downloading, the original configuration is still running with > the 4 leds down counting and the > nco running the two sine waves. I did change the default configuration of > the unused pins to inputs tri state. > I also downloaded all of the supplied configurations that came along with > the board. No effect. > > Anyone have any suggestions? > > Tks > Jer > > To answer my own post in case some one else has a similiar problem. You got to turn sw4 off on the dip switch.Article: 82615
It's not on a global clock line if it's the output of a LUT, that's why he said send the output of the LUT to a global clock buf. "g. giachella" <giachella.g@laben.it> wrote in message news:caea16ca.0504122217.8f4a11c@posting.google.com... > "Marc Randolph" <mrand@my-deja.com> wrote in message > news:<1113311589.903268.83150@z14g2000cwz.googlegroups.com>... >> Howdy, >> >> Depending on how you are getting signals between blocks A/B and C, >> there is the potential for trouble - but the MUCH bigger problem is >> that you will have unacceptable skew *within* block C. Unless you >> floorplan the flops within block C (and do so VERY intelligently), >> you're asking for trouble. Even if you do the muxing with LUTs, send >> the output of the LUT to a global clock. >> >> And yes, the skew within blocks A and B should be fine. >> >> Marc > > Could you clarify this point ? Why shouldn't the skew inside block C > be low, assuming it is also an a global clock line ? > > ThanksArticle: 82616
soos, Was it: http://www.dyneng.com/pci_lvds.html or, another one of the 907 hits on google for: LVDS Xilinx PCI card I was just using google to find the card. A lot of links to wade through. Good luck, Austin soos wrote: > Austin, hello > > Thank you for your reply. I have visited the site you mentioned but > failed to find > an LVDS card with a pci interface. > > I have noticed that you are a Xlinx member, could you point other > companies that implement LVDS on your FPGAS? > > Thanks in advance, and sorry to bother you, > Marc. >Article: 82617
Stephane wrote:
>
> Thank you guys for your feedback!
>
> I am to understand that a 32b selectMap is reserved for future use,
when
> 7.1i will be stable, and xilinx engineers more available...
>
> Ok, but how can the internal conf logic detect what is the kind of
> incoming bistream? As soon as the syncro words? In that case, one can
> not place any garbage on D[31..8], as they might be badly
interpreted!
Howdy Stephane,
I have no idea how they really do it, but one simple way would be to
ignore the contents of D[31..8] until after you decide it should switch
to 32 bit mode:
32 bit mode 8 bit mode
D32 D0 D32 D0
XXXXXX32 XXXXXX08
[START 32 BIT MODE] XXXXXXXX
5678ABCD XXXXXXXX
XXXXXXXX (or 08 could be here)
[START 8 BIT MODE CONFIGUATION]
XXXXXXCD
XXXXXXAB
...etc
X's are obviously don't cares.
BTW, I neglected to mention something on my original reply about the
configuration time: it is only that low (10 msec) if you can really
feed a byte to the part on every clock cycle. If you are driving the
selectMAP from a microprocessor, that may not be possible since it can
take them many cycles for each bus access.
Marc
Article: 82618
Howdy Simon,
I forgot to explain why I mentioned 99% slice usage... doing so
should help confirm your (correct) understanding of unrelated logic.
The tools actually output a message that explains unrelated logic:
NOTES:
Related logic is defined as being logic that shares connectivity -
e.g. two LUTs are "related" if they share common inputs.
When assembling slices, Map gives priority to combine logic that
is related. Doing so results in the best timing performance.
Unrelated logic shares no connectivity. Map will only begin
packing unrelated logic into a slice once 99% of the slices are
occupied through related logic packing.
Note that once logic distribution reaches the 99% level through
related logic packing, this does not mean the device is completely
utilized. Unrelated logic packing will then begin, continuing until
all usable LUTs and FFs are occupied. Depending on your timing
budget, increased levels of unrelated logic packing may adversely
affect the overall timing performance of your design.
(taken from
http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/sim/sim0020_5.html)
So as you can see from the output message, until it reaches 99%, the
tools almost go out of their way to use up slices before starting to
work a bit harder and put things that don't share inputs together. If
your unrelated logic is 0%, there is still considerable headroom above
99%. It's only when unrelated logic packing auto-activates that you
need to be concerned about being over 99%, and even then, it varies
drasticly by design. Here is the output of one design I helped with a
few years ago in ISE 5.3.3i:
Logic Utilization:
Total Number Slice Registers: 10,129 out of 18,560 54%
Number of 4 input LUTs: 13,491 out of 18,560 72%
Logic Distribution:
Number of occupied Slices: 9,278 out of
9,280 99%
Number of Slices containing only related logic: 5,259 out of
9,278 56%
Number of Slices containing unrelated logic: 4,019 out of
9,278 43%
[note that it is ONLY saying that 43% of the used slices contain
unrelated logic... it isn't saying that utilization is 99% + 43%, or
anything like that]
BTW, this whole discussion about unrelated logic usage only applies if
you leave the -timing option for MAP turned off (at least in ISE 6.x or
7.x). If -timing is turned on, I believe that slice packing is done
differently such that you won't get an unrelated packing number... in
theend, with -timing you should get better results, but it keeps the
designer a little more in the dark about how full the design really is.
None of this changes the fact that since your total slice usage is less
than your target device, so it should fit with no problems.
Here is another explaination of unrelated logic:
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=12191
Summary: in some instances, it can adversely affect routability or
routing delays. In short, it varies by design. :-)
Good luck,
Marc
Article: 82619Anthony Mahar wrote: > As they state in their paper > http://cag.csail.mit.edu/warfp2005/submissions/29-suh.pdf > > "In our initial study, we deploy a monitoring capsule in Dcaches to mon- > itor the memory behavior between a CPU and L1 Dcache." > > It is not possible to monitor signals between the CPU and L1 cache (I or > D). Was the monitoring of CPU/L1 inferred by the cache misses seen > coming from L1? They had two versions of their monitor--one for the MicroBlaze core and one for the PPC. For the PPC, they inferred the cache missess as seen from the L1. With the uBlaze, since they have access to the L1 cache signals, they could wedge their monitor in it. >Even so, a lot of memory behavior is missed when only > observing cache misses. > > Regards, > Tony > > Nju Njoroge wrote: > > Anthony Mahar wrote: > > > >>Nju Njoroge wrote: > >> > >>Interesting question for the "Monitoring Capsule Design" paper... > > > > they > > > >>state they monitor behavior "between the CPU and L1 Dcache." Did > > > > they > > > >>explain how they were able to do this, since the PPC405 and L1 are > > > > part > > > >>of the same hard core? > >> > > > > You are right--the CPU and the L1 cache are in the same hard core, so > > we don't have access to the interface inside the CPU core and the > > cache. As I described in my previous post, they placed their monitor at > > the interface of the L1 cache port that are usually connected to the > > PLB. Thus, instead of connecting their CPU to the PLB bus, they > > connected the PPC core to their monitor, which is then connected to the > > PLB. > > > > NN > >Article: 82620
Hi, I was wondering if anyone has any advice or experience on the following: I need to clock some logic with a clock signal that is connected to an I/O pin (PCB design constraint!). What are the consequences of connecting this signal to a DCM input? I'm assuming it's possible... Does anyone have any recommendations? I'm using Virtex II Pro and the clock signal is in the 100MHz range. thanks.Article: 82621
I think your conclusion about three kinds of people is very classical.I hope that we will have more intercommunion. > Antti Lukatswrote: "strayblue" <strayblue2003@yahoo.com-dot-cn.no-spam.invalid> schrieb im > Newsbeitrag news:lt6dnd2PNq8vYcbfRVn_vg@giganews.com... > Thank you very much,I will learn to do it,and will do it better. > thats better attitude, I belive that if you do, you can do it. better. The links I provided do not give anything quite ready to use, just those starting points known to me. Hopefully there was some usefulness in it. And hope you didnt mind my writing style, I am very open, so I say what I think. So get a Smile and start doing. And try keep smiling :) Antti BTW I am at the moment quite engaged with JTAG from different aspects, both from master and slave side and also in supporting software, so if you make something better, please keep me posted, or better would be if there would be some result from your work that could be used by others. [[/quote:a8cad9cfa2]Article: 82622
downunder wrote: > Hi, > > I was wondering if anyone has any advice or experience on the > following: > > I need to clock some logic with a clock signal that is connected to an > I/O pin (PCB design constraint!). What are the consequences of > connecting this signal to a DCM input? I'm assuming it's possible... > > Does anyone have any recommendations? I'm using Virtex II Pro and the > clock signal is in the 100MHz range. Howdy, Yes, it should be possible. You'll probably pick up a little jitter, and definitely will have a phase offset due to prop delay, but probably nothing that is a show stopper. You didn't say if you need to clock I/O signals into the part with this clock. Or out of the part. For the out direction, is there a requirement that the I/O's toggle with a particular phase relationship to the input clock? If you do have I/O requirements, I believe you can work around it by using the fixed phase offset of the DCM to dial in a compensation for the prop delay of the input buffer, internal routing to the DCM, GBUF, and global clock delay - may take a few experiments to get it right. I/O requirements are the toughest thing to meet with a situation like yours, but at 100 MHz, it should be doable by locking down the routing from the input IOB to the DCM(s). If you have lax or no I/O timing requirements, most of the above doesn't apply and your job will be even easier. Good luck, MarcArticle: 82623
Amora wrote: > I couldn't find any information regarding the price of Xilinx's new > TMRTool. Does anybody happen to be interested in knowing the price of > this tool? The Xilinx webpage says contact your local sales office for pricing: http://www.xilinx.com/products/milaero/tmr/index.htm However I'd be surprised if this is not subject to export control. Rad-hard electronics systems (and design tools) come under US Govt. ITAR (International Traffic in Arms Regulations) restrictions. It would be interesting to hear what your local Xilinx sales office has to say on the matter. Regards, JohnArticle: 82624
Thank you Jon Kishore
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