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
Hello All,
The TimingAnalyzer can be used to draw and document
timing diagrams of digital systems.
A new version beta0.60 is now available. Registration is
no longer needed so a password is included.
This version includes a significant change in the GUI.
You can edit mulitple timing diagrams displayed in
tab panes or views. You can see this at:
http://members.aol.com/d2fabrizio/main_pic.html
Below is a complete list of all the changes.
Regards,
Dan Fabrizio
d2fabrizio@aol.com
http://members.aol.com/d2fabrizio
--------------------------------------------------------------------------
-------------------------------------
Version 0.60
New Features
1 A major change in the GUI.
Multiple diagrams can be displayed in tabbed panes.
Any tab pane can show the timing diagram or image diagram.
2 Multiple views, top and bottom, can display multiple timing diagrams.
Cut, copy, paste objects between visible diagrams in the top and
bottom views. In future, drag and drop will be added.
3 Diagrams left open when quitting are automatically loaded
when started again. A file called .taOpenFileList in the
user home dir keeps a list of files being edited between sessions.
4 Double click on any edge to change the edge time or next state.
5 Mouse drags all edges selected.
Left and right arrow keys also move edges as before.
6 Mouse drags all text objects selected.
Left and right arrow keys also move text objects as before.
7 Clock Divide by N function.
8 Edge Detector function.
Improvements
1 Digital Bus state format ( Hex, Bin, Dec, or Text ) can be
changed at anytime. Conversion from and to Text has been added.
2 More consistent dialog operation when updating or adding Objects.
3 Improved file I/O performance. ( file format change )
4 DigitalBus now displays "0" and "1" correctly.
Article: 37201
Austin,
Thank you for valuable information.
So, if I want to reduce the jitter on XILINX output to something like 10
ps - I have to use some external triggers, clocked by extremely pure
frequency.
And here the next question appears:
who manufactures low noise triggers?
Is that true, that regular ALS logic flip-flops are introducing 15 - 20 ps
jitter?
I guess, of course, there are some better triggers, - at least for expensive
jitter-measurement systems.
What kind of triggers?
Thanks,
Alex
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3C0B9EB9.AAFCC010@xilinx.com...
> Alex,
>
> I prefer to look at this as "what is the jitter noise floor" in a CMOS
FPGA?
>
> Getting in, and getting out of the FPGA is the biggest problem, followed
by the
> internal distribution of the clock signals.
>
> This is something we have carefully characterized, as we are the 'FPGA
Lab'
> responsible for the verification of the design.
>
> To get in, get onto a BUFG (global clock resource) and then get out (by
using
> the DDR clock forwarding FF's) is about 35 to 55 ps P-P (nothing else
> happening).
>
> If you have an another BUFG operating, the jitter goes up to 55 ps to 65
ps P-P.
>
> If you then have 10% of all nodes in a 2V3000 all toggle at the same time
on the
> same clock domain (BUFG), the jitter measured is ~ 150 ps P-P on an
> ansynchronous clock domain.
>
> The primary means of jitter is the coupling through the ground, which
affects
> the slicing level of all of the logic.
>
> Use of LVDS input buffers, and output buffers helps for the external
jitter
> contributors, but does nothing for the internal contributors.
>
> 150 ps P-P of jitter in a design was ignored up until recently. With DDR
> (double data rate) logic designs, and clock periods of 4 ns in some
designs, the
> half clock period is 2 ns, and 150 ps becomes a significant part of the
timing
> budget.
>
> See:
>
> http://www.xilinx.com/support/techxclusives/slack-techX21.htm
>
> Austin
>
> Alex Sherstuk wrote:
>
> > Dear colleagues,
> >
> > Some time ago there was discussion about phase noise (jitter) introduced
by
> > XILINX FPGA DLL's
> >
> > Here is an other question:
> >
> > What phase noise (jitter) is introduced by a regular logic element of
XILINX
> > FPGA (e.g. SPARTAN2)?
> > What is the timing uncertainty introduced by XILINX CLB trigger?
> >
> > Thanks,
> > Alex
>
Article: 37202Simon Gornall <simon@gornall.net> writes: > FPGA's are the new 80's PC's > I do feel there is some merit in the statement that FPGA's are now at > the point where PC's were at 15 years ago. Ah, someone to my liking :-). > I would *really* like > to not have to reboot into Win2k to run the tools though - in fact the > main obstacle to the development of my "project" is that my Linux box > is usually busy doing things, and I don't want to interrupt it to play > on the FPGA stuff. Guess I should buy another computer ... You seem to not know that you can develop for Virtex (without -E) and those Spartan-II models that have equivalent Virtex sizes under Linux. I am initially targetting the same BurchED board, and I have been 100% Microsoft-free for 5 years now. And I do not have a Solaris box either. The trick is to use Xilixes JBits toolsset. It is also a free (as in beer) download from Xilinx. Only problem is that since 2.6 the installer craps out under some Linux distributions (Debian and Slackware for sure), so one needs to borrow time on an Solaris box to do the install there, then .tar.gz it and unpack on Linux. JBits is a bit unusual in that is is totally low-level (you trigger individual chip features). For a look at how using it is like, try my project source at: http://neil.franklin.ch/Projects/PDP-10/pdp10.java -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 37203
rickman <spamgoeshere4@yahoo.com> writes: > Neil Franklin wrote: > > > > My method to save time is to actually have no bus at all. Rather > > SDRAM sockets and set of standard IO connectors driven directly > > (or with only a bit of analog stuff between) from the FPGA. "Bus" > > is only internal, longlines or even user multiplexers. Also gives > > maximal flexibility to different architectures. > > Exactly what do you consider to be a "standard" IO connector? Oops. That term can be misunderstood. :-) > I assumed > that you meant PCI, ISA, IDE ect. I was thinking of VGA, PS/2, LPT, RS232, FDD, IDE, Ethernet and so on. > If you want to put all that interface > inside of the FPGA that will require more work on your part to design > the interfaces. As I have got to clone the register sets of the historic IO devices, actually implementing the functionality should follow. > If you use an existing MB, you only have to design your > CPU with a single bus interface. And then port the old systems OS to an totally new memory map and IO devices. I know from the original historic systems developers who are following my project, that such an port was for them a multi-year job. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 37204
Andy Peters <andy@exponentmedia.deletethis.com> writes: > Neil Franklin wrote: > > > Presently my real application is my design for running on such an > > board (and being developed on an normal prototype board). Custom board > > will follow after, to let more users use the design with less hassle. > > What's a "normal prototype board"? Don't tell me you're gonna wire-wrap > this thing. Present intended board is the BurchED XC2S200 prototype board. For the newest revicion (B5) that gives 8 20pin connectors. What I will be putting on them I will decide when I am so far. > Question: which open-source PCB layout tool will you be using for your > custom circuit-board layout? Not decided. Not even investigated the issue yet. As said: first coding for the BurchED, parallel developing some tools. Then when users want to use the design (in perhaps 2 years) a board will be needed. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 37205
Neil Franklin wrote: > > Simon Gornall <simon@gornall.net> writes: > > > FPGA's are the new 80's PC's > > > I do feel there is some merit in the statement that FPGA's are now at > > the point where PC's were at 15 years ago. > > Ah, someone to my liking :-). > > > I would *really* like > > to not have to reboot into Win2k to run the tools though - in fact the > > main obstacle to the development of my "project" is that my Linux box > > is usually busy doing things, and I don't want to interrupt it to play > > on the FPGA stuff. Guess I should buy another computer ... > > You seem to not know that you can develop for Virtex (without -E) and > those Spartan-II models that have equivalent Virtex sizes under Linux. Thanks for the info, Neil, I'll look into it :-) ATB, Simon.Article: 37206
mrgs1000@yahoo.com (Mark) writes: > I am doing some research on place and route tools. I would like to > collect as much information as possible about them. My primary focus > is on Xilinx, but I would like to know if there are particular > features on other vendors tools that you like or dislike. I like performance. Most place and route algorithms are building some kind of search tree with an estimate of timing, congestion, etc. I think these applications would run quite effectively on clusters of workstations (or PC's). I would like to see place and route tools implementing distributed algorithms so I could increase the throughput (not necessarily linearly) by throwing cheap $2000 PC's at the problem... Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 37207
I don't know for sure if the results are spectacular but when I was designing jitter test equipment for telecom, the approach I wanted to persue was to use single-gate registers. At the time the pico-gate devices (someone's trademark, I'm sure) or other associated small logic families didn't have registers shipping, only planned. The biggest reason jitter is introduced is crosstalk between elements within the same package. If there's only one element, how can you have crosstalk? The jitter steps down to even smaller effects. If you treat the registers as analog elements - clean planes, nice clearance on the traces to reduce crosstalk - you should get the clean edges you desire. But they'll never be more clean than the clock source that drives the registers - that *must* be clean. Alex Sherstuk wrote: > Austin, > > Thank you for valuable information. > > So, if I want to reduce the jitter on XILINX output to something like 10 > ps - I have to use some external triggers, clocked by extremely pure > frequency. > > And here the next question appears: > who manufactures low noise triggers? > > Is that true, that regular ALS logic flip-flops are introducing 15 - 20 ps > jitter? > > I guess, of course, there are some better triggers, - at least for expensive > jitter-measurement systems. > What kind of triggers? > > Thanks, > AlexArticle: 37208
Wow, This sounds exactly like my complaints about Lattice 5 years ago (I
haven't used Lattice in a while). So sad to hear that nothing has changed.
Andy Peters wrote:
> Well, here's a complaint about Lattice's tools.
>
> For some reason, Lattice thinks that designers care about how many logic
> levels it takes to implement a function. See, I don't care. All I care
> is that the finished design meets my timing constraints (and fits).
> Problem is, Lattice's tools don't know a timing constraint from a hole
> in the wall. What their tools expect you to do is to pick a combination
> of fitter options, press "go" and after the place and route completes
> (if, in fact, it does), you have to manually go through the timing
> reports to see if you win or lose. And when you lose, you have to go
> back in and pick a different bunch of options. The fitter "effort"
> switch doesn't do what you think it does, it just picks a different
> algorithm. The "Explore" feature is broken.
>
> If you want to take advantage of the fast I/O output enables, you have
> to set a constraint in a constraint file that's call "end critical
> path." And the fitter will then warn you that there's "no combinational
> logic..." to minimize if you drive your output enable from a flop. (It
> still "does the right thing," but the warning is stupid.)
>
> I've told the Lattice rep more than once: I want to be able to set a
> period constraint and I/O timing constraints, push the "start" button,
> and go get a cup of coffee or get some lunch, and come back and find my
> chip either routed or failed to meet timing (or it wouldn't fit).
>
> I haven't even mentioned how unroutable their chips are.
>
> ---a
--
--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: 37209John_H wrote: > I love seeing comments form others that reinforce the gripes I've had over > time. > > My experience with the Altera MaxPlus-II tools is dated with no Quartus to > back mu up but what I saw then is consistent with what I continue to see > in Xilinx: > > Nobody is doing "critical route" placement. Take a look at the TOPS technology in Amplify. It does it's own complete placement of a region while doing timing optimization on the logic. It doesn't do the whole chip but regions can be pretty large. Virtex and Virtex-E only. http://www.synplicity.com/about/pressreleases/SYB-101final.html > > In my opinion, the best way to place and route a design is to figure out > what paths will be the most difficult to route. When the delay paths with > two carry chains and four levels of logic are routed first, the paths with > two levels of logic should be cake to P&R with fewer resources available. > I don't care if my logic goes from one corner to another if it doesn't > impact the timing for that path and the critical routing resources have > already been used. What does irk me is finding part of my few tight paths > getting placed inefficiently. To have these critical paths in different > rows in my Altera design or in different, non-adjacent CLBs in my Xilinx > designs is irresponsible. > > The Xilinx mapper in particular works against the concept of a critical > route based place and route. The idea that the design should 1) be placed > then 2) be routed doesn't work (to any level of efficiency). The P&R tool > should be 1) place, 2) route, 3) place, 4) route, 5) place, etc.... At > least in (an upcoming servicepack of) the version 4.1i tools there's some > attention given to critical routes, though more of a ripup and retry > approach. Strike that, I think they refer to it as a retry: no ripup of > any paths that meet timing. This is a big step in the right direction but > still may be too little, too late in the P&R process to give the leaps in > performance. > > With the proper P&R strategies, the silicon that's been designed to kick > some serious butt will finally be able to do just that. Having the P&R > kick the engineer in the butt really needs to stop. > > I hope the research you're doing is toward a very good end! > >Article: 37210
Austin Lesea <austin.lesea@xilinx.com> writes: >I prefer to look at this as "what is the jitter noise floor" in a CMOS FPGA? >Getting in, and getting out of the FPGA is the biggest problem, > followed by the internal distribution of the clock signals. >This is something we have carefully characterized, as we are the >'FPGA Lab' responsible for the verification of the design. >To get in, get onto a BUFG (global clock resource) and then get >out (by using the DDR clock forwarding FF's) is about 35 to 55 ps >P-P (nothing else happening). >If you have an another BUFG operating, the jitter goes up to 55 ps >to 65 ps P-P. This reminds me of a story about the TTL 74S124 (I think that is the number) dual oscillator. I was told that it was almost impossible to use both, as they will phase lock if at all possible. As I remember, phase locked oscillations were first discovered by Huygens putting multiple pendulum clocks on the same wall. You wouldn't expect the coupling to be large, but apparently enough. OK, web search and I find: http://www.soundfeelings.com/products/alternative_medicine/music_therapy/entrainment.htm So, might one expect problems with multiple, non-synchronous oscillator inputs to the same FPGA? -- glenArticle: 37211
when i do a project,i need use many the thirdy EDA tool.They offen need various environment variable.Now i need a shell or script that can run the all tools i refer from begin to end ,but i don't need to switch. Have anyone done ?Article: 37212
On Mon, 03 Dec 2001 11:12:41 -0500, rickman <spamgoeshere4@yahoo.com> wrote: >Allan Herriman wrote: >> Here's the logic generated by crctool for one bit of a 16 bit CRC with >> 128 bit input word: >> >> D := Data; -- the input word >> C := CRC; -- the feedback word >> >> NewCRC(0) := D(127) xor D(125) xor D(124) xor D(123) xor D(122) xor >> D(121) xor D(120) xor D(111) xor D(110) xor D(109) xor >> D(108) xor D(107) xor D(106) xor D(105) xor D(103) xor >> D(101) xor D(99) xor D(97) xor D(96) xor D(95) xor >> D(94) xor D(93) xor D(92) xor D(91) xor D(90) xor D(87) xor >> D(86) xor D(83) xor D(82) xor D(81) xor D(80) xor D(79) xor >> D(78) xor D(77) xor D(76) xor D(75) xor D(73) xor D(72) xor >> D(71) xor D(69) xor D(68) xor D(67) xor D(66) xor D(65) xor >> D(64) xor D(63) xor D(62) xor D(61) xor D(60) xor D(55) xor >> D(54) xor D(53) xor D(52) xor D(51) xor D(50) xor D(49) xor >> D(48) xor D(47) xor D(46) xor D(45) xor D(43) xor D(41) xor >> D(40) xor D(39) xor D(38) xor D(37) xor D(36) xor D(35) xor >> D(34) xor D(33) xor D(32) xor D(31) xor D(30) xor D(27) xor >> D(26) xor D(25) xor D(24) xor D(23) xor D(22) xor D(21) xor >> D(20) xor D(19) xor D(18) xor D(17) xor D(16) xor D(15) xor >> D(13) xor D(12) xor D(11) xor D(10) xor D(9) xor D(8) xor >> D(7) xor D(6) xor D(5) xor D(4) xor D(3) xor D(2) xor >> D(1) xor D(0) xor C(8) xor C(9) xor C(10) xor C(11) xor >> C(12) xor C(13) xor C(15); >> >> (Switch to fixed point font.) >> >> Here's the logic you'll end up with: >> >> clock-----------------------+ >> | >> +-------+ +----------+ >> | huge | | register | >> input-->| xor |----->|d q|--+-> CRC out >> (128) | tree | (16) | | | (16) >> +-------+ +----------+ | >> ^ | >> | | >> +------------------------+ >> feedback (16) >> >> The "speed" is determined by the minimum clock period, which in this >> case is limited by the number of logic levels in the xor tree - i.e. >> the maximum delay between any flip flop output and any flip flop >> input. >> You can't do anything with this directly, as the feedback must happen >> in a single clock cycle. >> >> If you look more closely at the logic expression, you'll see that it >> can be decomposed into the form (input xor feedback) where input is >> the xor of a bunch of input bits, and feedback is the xor of a bunch >> of feedback bits. >> >> This leads to the following design: >> >> clock--------------------------------------+ >> | >> +-------+ +-------+ +----------+ >> | medium| | small | | register | >> input-->| xor |----->| xor |----->|d q|--+-> CRC >> (128) | tree | (16) | tree | (16) | | | out >> +-------+ +-------+ +----------+ | (16) >> ^ | >> | | >> +------------------------+ >> feedback (16) >> >> This isn't any faster than the first attempt, but notice that the >> "medium xor tree" is not in the feedback path. This means it can be >> pipelined - we can put flip flops in the logic so that the calculation >> is performed over several clock cycles. The logic depth between any >> flip flop output and any flip flop input is reduced - we can have a >> faster clock. >> >> This is shown here: >> >> clock-----------------------+----------------------------- >> | >> +-------+ +----------+ +-------+ +- >> | medium| | register | | small | | >> input-->| xor |----->|d q|----->| xor |----->|d >> (128) | tree | (16) | | (16) | tree | (16) | >> +-------+ +----------+ +-------+ +- >> ^ >> | >> +------------ >> feedbac >> >> (I pruned the right side to avoid line wrap, but you should get the >> idea.) >> >> In theory the synthesis tools can do all this for you. E.g. you can >> describe a serial CRC calculation, put it in a for loop to iterate >> over the input word, tell it how many clock cycles to take, and the >> synthesiser should spit out something equivalent to the above. >> (I have used this approach with LFSRs with some success at these bit >> rates.) >> >> I could make a comment about the relative benefits of HDLs and >> schematics for high speed design, but I don't want to ignite yet >> another religious war. >> >> Regards, >> Allan. > >I am not clear about how you generated this logic, but it does not match >the general problem. Even though there are only 16 bits in the CRC, >there should be 128 bits in the "feedback" register as well as in the >input. Are you sure about this, Rick? I checked with other engineers here, and I checked a design that's happily generating CRCs in the field, and it all points to a CRC-n needing exactly 'n' bits of feedback regardless of the input word width. Perhaps you are trying to solve a different problem? Regards, Allan.Article: 37214
Hi I am trying to synthesise a simple receiver module. But I always get the error as above done: failed with exit code 0002. It says that the module is correct for synthesis - extracts several signals before failing. Can someone tell me what this means please BrindaArticle: 37215
Allan Herriman wrote: > >I am not clear about how you generated this logic, but it does not match > >the general problem. Even though there are only 16 bits in the CRC, > >there should be 128 bits in the "feedback" register as well as in the > >input. > > Are you sure about this, Rick? > > I checked with other engineers here, and I checked a design that's > happily generating CRCs in the field, and it all points to a CRC-n > needing exactly 'n' bits of feedback regardless of the input word > width. > > Perhaps you are trying to solve a different problem? > > Regards, > Allan. Or perhaps I am not remembering it correctly. I worked on this a year ago and helped another engineer with a 128 bit version while I worked on an 32 bit version. I may remember the details wrong. If the feedback is only n bits, then getting the speed should be a slam dunk as long as you can use pipelining for the inputs. -- 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: 37216
On Tue, 04 Dec 2001 00:06:55 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:
>Allan Herriman wrote:
>> >I am not clear about how you generated this logic, but it does not match
>> >the general problem. Even though there are only 16 bits in the CRC,
>> >there should be 128 bits in the "feedback" register as well as in the
>> >input.
>>
>> Are you sure about this, Rick?
>>
>> I checked with other engineers here, and I checked a design that's
>> happily generating CRCs in the field, and it all points to a CRC-n
>> needing exactly 'n' bits of feedback regardless of the input word
>> width.
>>
>> Perhaps you are trying to solve a different problem?
>>
>> Regards,
>> Allan.
>
>Or perhaps I am not remembering it correctly. I worked on this a year
>ago and helped another engineer with a 128 bit version while I worked on
>an 32 bit version. I may remember the details wrong. If the feedback is
>only n bits, then getting the speed should be a slam dunk as long as you
>can use pipelining for the inputs.
I make it that the clock rate is more-or-less determined solely by the
feedback, i.e. by the CRC order ('n'). For an 'm' bit input word, the
throughput is proportional to 'm'. Just make the input bus wider, and
you get more bits per second, without limit!
You don't get something for nothing, though, as the number of
pipeline stages on the input bus is something like O(log m), and the
number of flip flops is something like O(m log m).
Bye,
Allan.
Article: 37217> http://208.129.228.206/solutions/kits/xilinx/spartan-iipci.html > > I used this kit to develop my own PCI IP core, and although the PCI IP > core doesn't meet 33MHz PCI's timings (Tsu < 7ns and Tval < 11ns), the > card somehow (barely) worked in two computers I tested it. > It would have been nice if the Insight Electronics Spartan-II > Development Kit used a 200K system gate part (XC2S200) instead of a > 150K system gate part (XC2S150) even if the kit cost another $50 more, > but overall I am very happy with the Insight Electronics Spartan-II > Development Kit. What does "barely" worked really mean? I'm not intimately familiar with PCI-protcol...I know that the PCI bus outputs (on a device) are unregistered, to respond to the bus-protocol. Are you saying that the XCS2-150-5 device was barely fast enough to meet 33MHz timing? Xilinx brazenly boasts that their Virtex family (the old 0.25micron family) supports PCI66MHz/64-bit. Your experience suggests that while this can certainly be true, it's not an easily achievable target for someone not designing specifically for FPGA. Someone I know wants to develop a PCI-core for an in-house project. He threw around the idea of prototyping it on an FPGA-board. I advised him against it, simply because a lot of his design implementation would be governed by the FPGA's architectire (vs the actual production goal of a standard cell ASIC process.) I reasoned he'd be wasting a lot of dev time making the core work on an FPGA-device, i.e. wasting dev-time "designing for FPGA", instead of just designing for the final project goal. sorry if this is a redundant question...Article: 37218
IIRC, the VirtexE was the first family they claimed for 66MHz 64 bit. To
get there, you need to use the TRDY logic that is embedded along the sides
of the array. The synthesis tools and even the mapper and pAR don't know
about this little added logic, so if you need to use it, you have to go into
the FPGA editor and add it to the design. Without it, I think you'll find
that you won't hit the 66 MHz 64 bit PCI spec, certainly not for the
original 2.5v Virtex, and I'm pretty sure not for the Virtex E either.
sdfjsd wrote:
> > http://208.129.228.206/solutions/kits/xilinx/spartan-iipci.html
> >
> > I used this kit to develop my own PCI IP core, and although the PCI IP
> > core doesn't meet 33MHz PCI's timings (Tsu < 7ns and Tval < 11ns), the
> > card somehow (barely) worked in two computers I tested it.
> > It would have been nice if the Insight Electronics Spartan-II
> > Development Kit used a 200K system gate part (XC2S200) instead of a
> > 150K system gate part (XC2S150) even if the kit cost another $50 more,
> > but overall I am very happy with the Insight Electronics Spartan-II
> > Development Kit.
>
> What does "barely" worked really mean? I'm not intimately familiar
> with PCI-protcol...I know that the PCI bus outputs (on a device)
> are unregistered, to respond to the bus-protocol. Are you saying that
> the XCS2-150-5 device was barely fast enough to meet 33MHz timing?
>
> Xilinx brazenly boasts that their Virtex family (the old 0.25micron
> family) supports PCI66MHz/64-bit. Your experience suggests that
> while this can certainly be true, it's not an easily achievable
> target for someone not designing specifically for FPGA.
>
> Someone I know wants to develop a PCI-core for an in-house project.
> He threw around the idea of prototyping it on an FPGA-board.
> I advised him against it, simply because a lot of his design
> implementation would be governed by the FPGA's architectire
> (vs the actual production goal of a standard cell ASIC process.)
>
> I reasoned he'd be wasting a lot of dev time making the core
> work on an FPGA-device, i.e. wasting dev-time "designing for
> FPGA", instead of just designing for the final project goal.
>
> sorry if this is a redundant question...
--
--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: 37219Hi all gurus out there, First of all, a million thanks to Allan for the write-up. It all makes sense now. Any way, I did some binary long division manually (word by word rather than bit by bit) to have a feel of how the xor logic is generated. It becomes clear to me that whatever the input word length, the number of bits that have to be "carried over" to the next word is only C=number of CRC bits. And these are the feedback bits to the small xor tree in Allan's diagram. If we can pipeline the input word, increasing the input word length will not have any impact on the circuit speed. This looks almost magical to me. :-) But so far I am convinced it works. By the way, is there any web site/book which have a list of such interesting digital design problems? I love brain teasers like this (although I am lousy at solving them). Thanks. TA TA kahheanArticle: 37220
I will like to know if there is a way to increase clock skew by about 1.0 ns through a .UCF file (User Constraint File). I am having problems meeting Tsu (setup time), and adding 1.0ns of clock skew won't totally solve my problem, but it will help. I will like to add the clock skew through a .UCF file because the HDL code has to be portable across different FPGA vendors (mainly Xilinx and Altera). The device I am using is Xilinx Spartan-II 150K system gate part (XC2S150-5), and the software I am using is Xilinx ISE WebPack 4.1. Kevin Brace (don't respond to me directly, respond within the newsgroup)Article: 37221
Utku Ozcan <ozcan@netas.com.tr> wrote in message news:3C0B97EC.CF2A0C30@netas.com.tr... > We need such a PROM that can program two Spartan-II > XC2S50-5FG256Cs at the same time. > > XC2S50 has configuration file size of 559.200 bits. > So we need a PROM of size of = 2 x 559.200 = 1.118.400 > bits. > > The devices I have found are > > XC17S00A 3.3V XC17S200A one time programmable > XC17V00A 3.3V XC17V02 in system programmable > > The problem is, we need an OTP SPROM but our Data I/O > Programmer device only supports XC17S00 and XC17S00XL > devices but not XC17S00A devices. > > However, when I have looked at the datasheets of XC17S00/XL > http://www.xilinx.com/support/programr/files/17s00.pdf > and datasheet of XC17S00A http://www.xilinx.com/partinfo/ds078.pdf > I see that the internal logic of these devices are the same. > I haven't found any difference. > > XC17S00/XL family doesn't have any PROM that can hold two > Spartan-II XC2S50 at the same time. On the other side > Xilinx doesn't say that Spartan II devices can be programmed > with XC17S00/XL PROMs. > > The reason why we look at XC17S00/XL devices for Spartan-II > is that our Data I/O Programmer only supports XC17S00/XL > devices. > > I have thought that XC17S00/XL in Data I/O Programmers are > compatible with XC17S00A PROMs, therefore I can use XC17S00/XL > mode in Data I/O Programmer to program XC17S00A PROMs. Hi Utku, I asked the same question to a Xilinx support person, and got the answer that the programming algorithms for the XC17S00XL and the XC17S00A PROMs are different. You need a programmer that supports XC17S00A to program them. Regards, Karl OlsenArticle: 37222
Kevin Brace <kevinbraceusenet@hotmail.com> wrote: > I will like to know if there is a way to increase clock skew by about > 1.0 ns through a .UCF file (User Constraint File). > I am having problems meeting Tsu (setup time), and adding 1.0ns of > clock skew won't totally solve my problem, but it will help. > I will like to add the clock skew through a .UCF file because the HDL > code has to be portable across different FPGA vendors (mainly Xilinx > and Altera). > The device I am using is Xilinx Spartan-II 150K system gate part > (XC2S150-5), and the software I am using is Xilinx ISE WebPack 4.1. Clock skew figures quoted by TRCE/Timing Analyzer are only maximum values anyway -- the actual skew in the real silicon could be anything from that value down to zero (perhaps even negative). So even if you could add that skew, it would only add to the maximum, not necessarily the actual. You could daisy chain the global buffers or something like that. You could use the phase shift if you had a Virtex-II. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 37223
rickman <spamgoeshere4@yahoo.com> wrote: > On the other hand, place and route algorithms are in a class of problems > known as NP complete if my schooling has not failed me (or my memory). > This means essentially that you can NEVER deterministically find the > best solution to the problem for a realistic application given the state > of technology in the foreseeable future. At least this is true until we > are using Quantum computing which can explore all solution sets > simultaneously. This may be true, but it says nothing of the ability of the open source community to deliver a PAR tool equivalent in quality to Xilinx's or Altera's. After all, neither Xilinx or Altera are delivering a PAR tool which can deterministically find the best solution, as far as I can tell :-) Of course the chip vendors will always have the inside information on the chip. In fact, they are the only ones with the information on the chip presently, since they don't release enough details for anyone else to create a bitstream. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 37224
John_H <johnhandwork@mail.com> wrote: > Nobody is doing "critical route" placement. Good point. I had to do something like this by hand using guide files etc earlier in the year. Really ugly, but the end result worked out OK. Unfortunately, the guide files aren't compatible between 3.x and 4.x! > With the proper P&R strategies, the silicon that's been designed to kick > some serious butt will finally be able to do just that. Having the P&R > kick the engineer in the butt really needs to stop. Well put. cheers Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
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