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
Theron Hicks <hicksthe@egr.msu.edu> wrote in message news:<3BFAD1CC.68FFCCEA@egr.msu.edu>... > By the way, the purpose of this code is give me a very precise > measurement of a pulse width. The main clock is 200MHz, thus, in > theory, the resolution is equivalent to using a 3.2GHz clock. If you have enough time between samples, you could use a simple sequential circuit to measure your string of 1's. Otherwise, use carry chains. You can use a carry chain to implement a Find-First-One circuit. Use one of these in each direction to measure the start and end of your string of bits. Depending on how your patterns wrap, you may need two circuits to mesaure both 0's and 1's. You could also consider using the carry chains instead of multiple clocks to do the timing capture. The carry propagation for a virtex2 is about 100ps (max) per stage. You can probably string enough of these together to span the 2.5 ns half-period of your 200 MHz clock. Then you will need two chains, one gets captured in the rising clock, the other on the falling clock. If you're lucky, you may also be able to configure the same carry chain to implement the Find-First-One function on the captured pulse. You will need a way to calibrate the carry delay. Probably the best way is to provide a path to inject calibration pulses into the circuit.Article: 37076
Hi all, i have problems when i try to install xilinx foundation 3.1 on a p4 system. i heard that the program is not compatible with this processor, is that true? if yes, what do i need to download to make the program run properly? Take care HarrisArticle: 37077
Thank you for your reply.
This is a paying job. For OpenCores, I am currently working on a
development board, at board level (schematic, PCB).
Unfortunately, in the past year, my time available for OC activities
almost disapeared ... Now, I restarted the activity. I hope that soon
there will be seen some results.
Best regards,
Ovidiu Lupas.
> Just out of curiosity, is this a paying job or for the open cores thing?
> I might be able to get you some professional help if you are working on
> the open cores thing. That was meant in the EE sense, not in the psyc
> sense of professional help...
>
> BTW, you might also look at the implemented logic to see if
> optimizations are being done on the logic. There are a lot of duplicate
> terms in the equations you end up with and you should see sharing of
> logic between the bits. This can also slow you down a bit if done
> poorly. Not a bad place for hand optimization of the source code.
>
>
> --
>
> 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 FAX
Article: 37078
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C065266.E43453F@yahoo.com>...
> Neil Franklin wrote:
> >
> > mrgs1000@yahoo.com (Mark) writes:
> >
> > > Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
> k0l3mmebi1703urlud5e91rou5af@4ax.com>...
> > > >
> > > > I understand that the scarcity of such software is partly because
> > > > vendors do not release enough information. Are there any modern devices
> > >
> > > I would venture to say that the primary road block to open-source
> > > tools is that they are too dificult to support and keep current for
> > > people to do for free.
> >
> > As opposed to tons of video and ethernet chips that the Linux people
> > seem to have no great problem with?
> >
> > Just simply support those chips that members of the open source group
> > use. And the software users then buy those parts.
> >
> > Hint to vendors: if your part has open source support, it gets more
> > recommendations ("take that one, it works"), and you get to sell more
> > of them. I principially buy video and ethernet cards after consultion
> > the on-line support databases.
>
> I think this is where the analogy between standard hardware support
> under a standard OS and FPGA support under a standard tool fails.
> Designers don't EVER want to compromize their choice of chip based on
> the tools. That would be more like vacationing in Newark because the bus
> is cheaper than taking a plane to the Bahamas!
>
> The idea that open source tool support will significantly impact the
> sales of FPGA chips is weak at best. The customers who buy lots of chips
> from the FPGA vendors get free tools and often have an FAE parked in
> their facility. I worked at one place where they still used brand Z
> chips in SPITE of the awful toolset they had to use. This was because
> the chip was $10 cheaper than the other brand. It ended up costing them
> a lot when they had to make revisions, but this was still the best
> solution in terms of PROFIT!!! (brand Z is not meant to be any
> particular company!)
>
>
> > > There are lots of flows for design entry and
> > > simulation,
> >
> > Just support those that the present maintainers use. And use those
> > that are supported.
> >
> > > and new devices are released on a weekly basis. I
> >
> > Huh? As far as I see it Xilinx has so far created about 9 families
> > (2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
> > VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
> > (MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
> > in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
> > families (4000 6000). Actel I do not know, as I can not read their
> > website (damn Flash and not HTML alternative). And a few other
> > irrelevant manufacturers.
> >
> > So that makes about 2 falimies per year industrywide to support. Or
> > simply only support a few of them and only use those.
>
> But a familiy has some 10 different parts in it. Each of those parts has
> many packages and several speeds. Just getting the speed info (critical)
> is not an easy problem to solve. Without vendor support, you would be
> very hard pressed for anyone to trust your data.
>
> It certainly could be done, but the fact that it has not happened yet is
> a good indicator that it is harder than you seem to believe.
>
It’s actually even worse than that. Vendors are constantly
re-characterizing the parts and re-releasing updated timing models for
previously released parts. I haven’t paid strict attention, but
during a single design phase, the timing models will often get updated
on me at least twice.
This brings up another point, in addition to the place and route
tools, you have to also provide the timing analysis tools.
It’s true that new families don’t get released often, but
when they do, you have to practically throw out your place and route
software because the architecture changes are too drastic. I like
doing hand placement for critical circuits. When I switched from
Virtex E to Virtex II not only was all of my work in Virtex E
worthless, it was a hindrance
>
> > > occasionaly start using parts before they are released so I would not
> > > be able to wait for open-source tools to have the support. In fact, I
> > > have started designs where the vendors own tools didnt suport the part
> > > I was using.
> >
> > Does not look like you are an average user there. :-)
>
> Actually, I think he is a typical user. I think every place I have
> worked has used beta versions of the chips at one time or another. With
> a 4 to 6 month design time for an FPGA of any size, it pays to get
> started as early as possible.
>
To be clearer, I am a typical Tier One user of FPGAs. Meaning that the
companies I have worked for are high profile international accounts
for the FPGA companies. I cant say whether or not this makes me a
“typical” user since I don’t know the demographics
of all FPGA users from people like me down to hobbyists. However, I do
know that from a volume standpoint my group uses more FPGAs than any
other group. This means that the FPGA companies are mostly concerned
with users like myself. For us, spending hundreds of thousands of
dollars on 3rd party FPGA tools is no big deal. I say 3rd party
because we wont spend a dime on any software from the FPGA company.
They give us the tools free for the privilege of having us as a
customer.
It is true that an open-source community could support a limited
number of devices, and it could stay behind the technology curve where
specification churn is limited, and specification details are
plentiful (no longer NDA) but this group would be limited and most
likely restricted to hobbyists, students, and a few niche markets
which have little competition.
You can choose to debate this, however, the fact such tools
don’t exist is pretty good support for my argument.
Mark
Article: 37079"Bryan" <bryan@srccomp.com> wrote in message news:<3c0551b6$0$7684$4c41069e@reader0.ash.ops.us.uu.net>... > > > > This is not for the faint of heart, and is considered advanced even > > for Xilinx FAE's but it works great. Turn your little submodule into a > > hard macro. This will fix the placement and routing. The other nice > > thing about this is that every instatiation will be routed idencly, > > instead of randomly. I use it mostly for circuits that have clocks > > that are not on the globabl clock net. It's the only way I can > > gurantee that I get a good route on the clock net everytime. > > > > This will get you started: > > see Xilinx Answer Database record #10901 "FPGA Editor - How do I > > create a hard macro?" > > > > Oh, and make sure you use LOCs for every instantiation of the macro, > > otherwise your PAR time will go up, not down. > > > > Mark > > 5. To maintain the relative placement of the CLBs/Slices in the Macro, > select a CLB to use as the reference, and go to Edit -> Set Macro Reference > Comp. This will effectively create an RPM, and will make the system's timing > as consistent as possible. Keep in mind that it is impossible to lock down > routing, so there are no guarantees that the asynchronous paths will not > change. > > > This is from the answer record you mentioned. It says it is impossible to > lock routing, so how did you get the clock route locked down? > > Bryan I think they are referring to the routing of signals between the macro and the rest of the design. If you have fully placed and routed the design before turning it into a macro, then it will keep the routing. I know for a fact because I waste a lot of time just messing with routing to keep the macros from bumping into each other. It is stupid to do this flow for placement only since you can get the placement by just adding LOCs to the UCF file. MarkArticle: 37080
thank you very much <khtsoi@cse.cuhk.edu.hk> wrote in message news:9u4vtt$r89$1@eng-ser1.erg.cuhk.edu.hk... > H.L <alphaboran@yahoo.com> wrote: > > Hi all, > > i have problems when i try to install xilinx foundation 3.1 on a p4 system. > > i heard that the program is not compatible with this processor, is that > > true? if yes, what do i need to download to make the program run properly? > > > Take care > > Harris > > The Java runtime comes with 3.1i is not for P4 system. > The solution is to copy all the data from CDs to HDD and then > replace the java with the newly downloaded one. Finally install > the software from HDD. > ---- BrittleArticle: 37081
khtsoi@cse.cuhk.edu.hk wrote in message news:<9u3vgk$b5m$1@eng-ser1.erg.cuhk.edu.hk>... > Mark <mrgs1000@yahoo.com> wrote: > > Oh, and make sure you use LOCs for every instantiation of the macro, > > otherwise your PAR time will go up, not down. > Hi, > I still confuse at this point. If I create a *hard* macro, shouldn't it > contain all the placemanet and routing information need by par. Then > why should I use LOC inside the FPGA editors again? The LOC is not to constrain anything inside of the macro, it is to tell PAR where to place the macro. > Also, is there a way to do it in a high level (in VHDL level or enen UCF) > but not donwto to the FPGA editor? The reasons for this are: > 1. I don't always have access to the consol with *both* good display and > fast CPU. I usually write the VHDL codes on my laptop and submit > them to a SunE4500 machine though text mode. No fix for that, its graphical only. Actually that is not 100% true, but directly modifying the ncd file is so hard as to not be your consideration. > 2. Some one say (and what I always beleave is) that I can do every thing > in VHDL as the schematic method can. Isn't that true in this > case? (don't start a war on this, I just want to get my work done) Its a moot point, were talking about doing PAR manually which has nothing to do with schematic or VHDL. All you can do from schematic or VHDL is LOCs, and constaints. I abandoned schematics years ago so I cant speak to them. > 3. To ensure my instructions of LOCs in VHDL is correctly passed to par, > I have checked the PCF (physical constrain file) generated by map > tools. One interesting thing is that I can only find the LOCs from > top level (i.e. indicating where the submodules should be placed) > but not the LOCs inside the sum modules telling the locations of > the internal components. If this is the normal case, how can the > par tool know the information about the internal components? I mostly place LOCs in the UCF file and I dont use LOCs on parts of the design that get synthesized. For synthesized code I use area constraints in the floor planner. The reason is that post synthesized code can change every time you resysnthesize. For parts of the design I want to hand place with LOCs I code in FPGA primitives so that the synthesis tool cant change it. Coding in this way (verilog), I do have LOCs at the lower level, which make it into the final design. > 4. My sub moduls are not quite simple. It use up to a 6x4 CLB block and > use up all resource in that (including the TBUFs). Also, I am at > the dead line of my project and it's looks impossible for me to > get the schematic work within a day (I will finally do it after > the dead line if this is the only way, but my report will have > only estimated performance...so sad) > Thanks for those all help me and spent time to read my news. Thanks again! > > ---- Brittle Given what you have said, forget about hard macros for this design, it wont be worth the trouble and will guarantee that you completely miss your deadline. I would do area floorplanning at the top level modules only (cause that will stay someone consistent through synthesis cause top level modules names dont get changed unless you change them), and do LOCs on logic where you can. Both of these will decrease PAR time. They may also allow you to run the tools on the quickest settings and still get acceptable results. Good luck. MarkArticle: 37082
In article <c2088d4a.0111290138.10577818@posting.google.com>, Ovidiu Lupas <olupas@opencores.org> wrote: >Hi all, > >In my current project I have to implement scrambling and CRCs over a >128-bit data bus at a clock rate of 100 MHz. My combinatorial areas >are huge and I am having problems meeting the speed requirements. > >Could someone give me an hint how to overcome this problem ? >Any hints will be appreciated. What exactly are your scrambling requirements? For making your CRC fast, reduce the math by unrolling the CRC (it's pretty easy to do) to make wider X-or trees. 100 MHz should be no problem on a modern part, I have a Rijndael core I'm building in a Spartan II-5, it runs at >110 MHz. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 37083
Austin Lesea wrote: > Nurit, > > The "jitter filter" is a register that tells the control logic how often to update > the delay line taps. Think of it as how long to "filter" the input phase before > deciding to advance or retard the tap in the delay line. > Does the "filter" also vary the size of the tap update when it occurs ? > > I should have said "update rate or the tap adjustment rate." > > If there is a sudden change of 500 ps in phase, with the default settings it would > take ~ 10,000 clocks to adjust back to 0 error with the default settings. With the > minimum settings, it would take less than ~100 clocks. > > I assume that these settings are the "JF" number ? If so is there any advantage to be gained in changing it if, for example, I can tolerate more jitter than 150ps but I'd like to increase the max input cycle-to-cycle variation from the quoted 1nsec to allow for some clock stop/restart ?Article: 37084
rickman wrote: > > But the FT package is just a lower profile version of the FG package. > There are a lot of applications where height is very, very important. > Didn't you go to the web site to find the packaging data sheet? That is > where I found it. > You're absolutely right. Having a class 1 bad day made me blind (CVS crashed during an attempted remote checkin and scribbled junk over some files just after I found what seems to be the recurrence of an old Synplify bug. !? Should have stopped right there & gone out for a beer or 10). Apologies to Xilinx. I'm trying to imagine an app that needs a ~0.5mm height improvment & can only think of the reverse side of a PCI card where the max component height is 0.8'' IIRC.Article: 37085
Austin Lesea wrote: > Rick, > > Now we get into the 'voodoo' part of the analysis. > > With a number of devices in parallel the issue becomes complex. If each > device requires a current based on the voltage it sees across its terminals, > there is some small variation of this voltage to current behavior from die > to die, part to part. There is also some IR drop in each package, and > through the board. > > The text suggests that with four times the current, you will succeed, and > discusses how more than four times is not required even though the peak > current may exceed the minimum required. It does not imply you can use less > than four times the specification. > > No one can say with any certainty that the four parts will power ON with > less than four times the individual ratings, other than: we guard banded > the spec (so the actual current is almost surely less), they won't all > require the current at the exact same moment, any one device will have the > total current available to it if the others are not using it yet (or have > finished using it). > > Austin > > Is this current related in anyway to device configuration ? If there are multiple Spartan devices on board would staggering the release of the PROGRAM* pins help the situation ?Article: 37086
I'm not convinced of this. I'd say the reason that there's no open-source FPGA development system is that there are too few people capable of doing the work who've got the motivation (a) to create the thing, and (b) to maintain it. Has there ever been a well-written well-maintained open-source digital simulator for pre-FPGA parts? No ... Why? Too much work to create and maintain it. Too few people likely to share the work. Why should a job such as this be different. Dick On 28 Nov 2001 10:58:00 -0800, mrgs1000@yahoo.com (Mark) wrote: >Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90uk0l3mmebi1703urlud5e91rou5af@4ax.com>... >> Hi, >> >> I'm looking for an open-source implementation of the entire synthesis >> path for an FPGA, in particular placement, routing, and generation of a >> configuration file for the FPGA. Any pointers to such software would be >> greatly appreciated. >> >> Alternatively: >> >> I understand that the scarcity of such software is partly because >> vendors do not release enough information. Are there any modern devices >> for which this information *is* available? IOW, if I wanted to implement >> an open-source synthesis tool, which devices should I target? Again, >> recommendations would be greatly appreciated. > >I would venture to say that the primary road block to open-source >tools is that they are too dificult to support and keep current for >people to do for free. There are lots of flows for design entry and >simulation, and new devices are released on a weekly basis. I >occasionaly start using parts before they are released so I would not >be able to wait for open-source tools to have the support. In fact, I >have started designs where the vendors own tools didnt suport the part >I was using. It's a nice dream, but I doubt it will ever become a >reality. > >MarkArticle: 37087
Rick, See below, Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > Nurit, > > > > The "jitter filter" is a register that tells the control logic how often to update > > the delay line taps. Think of it as how long to "filter" the input phase before > > deciding to advance or retard the tap in the delay line. > > > > Does the "filter" also vary the size of the tap update when it occurs ? Nope. > > > > > > I should have said "update rate or the tap adjustment rate." > > > > If there is a sudden change of 500 ps in phase, with the default settings it would > > take ~ 10,000 clocks to adjust back to 0 error with the default settings. With the > > minimum settings, it would take less than ~100 clocks. > > > > > > I assume that these settings are the "JF" number ? If so is there any advantage to be > gained in changing it if, for example, I can tolerate more jitter than 150ps but I'd > like to increase the max input cycle-to-cycle variation from the quoted 1nsec to allow > for some clock stop/restart ? JF is it. The advantage is if you are trying to track a quickly changing input clock (set the filter large, as 2's complement, that is small, or faster updates). Anything out of the phase detector window will lead to an unlocked condition, regardless of the filter setting. But a faster update my allow you to stay within the window.Article: 37088
Rick Filipkiewicz <rick@algor.co.uk> writes: > Question: How big is the full WebPACK installation ? Is it possible > use wget to just filter out e.g. the JTAG programmer stuff ? It should be possible if somebody could select that particular option in ie under windows and give you the url. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 37089
Hello Wolfram: We posted our reference design schematics for our microcontroller IP core evaluation boards at: http://www.silicore.net/1657eval.htm These are in 'pdf' format, so you should be able to read them. One of them is on a Spartan 2 and does have a 5V I/O to an LCD display. It works just fine. If you look at the schematic I did use a set of power sequencing diodes too (although Xilinx claims that they can tolerate any power up sequence). We did a set of boards using Xilinx Spartan 2, Altera FLEX 10KE and Agere ORCA 3 parts. We wanted all three boards to be nearly identical to demonstrate how the microcontroller core is portable across all three FPGA parts. All three have three power supply voltages on the board, so I used the power sequencing diodes. Wade D. Peterson Silicore Corporation Wolfram Sieber <w.sieber@gmx.de> wrote in message news:3c06665b.120853558@News.CIS.DFN.DE... > Hi folks, > does anyone has any experience in SPARTAN II and 5V peripheral > components? > Are there any known issues about dying FPGAs which are connected to 5V > Busses etc. while powering up the system? > > I've got the strong feeling that SPARTAN 2 could dy, if the 5V > components are powered up before the FPGA supply is stable. > > Is it necessary to keep the peripherals 'disconnected' while powering > up? > > I'm glad about ANY information and espacially experience on the 5V > issue and eventually existing power-up sequence constraints. > > Thanx in advance > > WolframArticle: 37090
mrgs1000@yahoo.com (Mark) writes:
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C065266.E43453F@yahoo.com>...
> > Neil Franklin wrote:
> > >
> > > Hint to vendors: if your part has open source support, it gets more
> > > recommendations ("take that one, it works"), and you get to sell more
> > > of them. I principially buy video and ethernet cards after consultion
> > > the on-line support databases.
> >
> > Designers don't EVER want to compromize their choice of chip based on
> > the tools. That would be more like vacationing in Newark because the bus
> > is cheaper than taking a plane to the Bahamas!
Which quite a lot of people actually do. Select on price, that is, not
chose Newark.
> > The idea that open source tool support will significantly impact the
> > sales of FPGA chips is weak at best.
Short term they may not. Think long term: they pull in more beginners,
and so in time grow the population of FPGA developers, and so allow
firms to emply more and so make more FPA projects and that sells more
chips.
> > chips in SPITE of the awful toolset they had to use. This was because
> > the chip was $10 cheaper than the other brand. It ended up costing them
> > a lot when they had to make revisions, but this was still the best
> > solution in terms of PROFIT!!!
If you are at 100'000 or even 1 mio sized series, no doubt this
holds. But at 100 parts chip cost is not relevant. Tool support is.
> > > > and new devices are released on a weekly basis. I
> > >
> > > So that makes about 2 falimies per year industrywide to support. Or
> > > simply only support a few of them and only use those.
> >
> > But a familiy has some 10 different parts in it.
And a Virtex CLB is a Virtex CLB, whether in XCV50, XCV1000 or XC2S200.
> > Each of those parts has
> > many packages
Inserting pin out tables is not that much work.
> > and several speeds. Just getting the speed info (critical)
> > is not an easy problem to solve. Without vendor support, you would be
> > very hard pressed for anyone to trust your data.
That may be important for the n*100MHz croud. Not everyone is playing
up there. Just all the potential sound processing applications, for
one, 48kHz anyone?
> > It certainly could be done, but the fact that it has not happened yet is
> > a good indicator that it is harder than you seem to believe.
So long non-availability of information makes it impossible, any "not
happened" is 100% explained. Everything else remains speculation until
that barrier falls.
> It’s actually even worse than that. Vendors are constantly
> re-characterizing the parts and re-releasing updated timing models for
> previously released parts.
Again only relevant to the top speed crowd.
> This brings up another point, in addition to the place and route
> tools, you have to also provide the timing analysis tools.
You know how many home/edu people overclock CPUs? Raise frequency until
crash, than drop by 10% is the sort of algorithm. It is "good enough"
for the target audience.
> It’s true that new families don’t get released often, but
> when they do, you have to practically throw out your place and route
> software because the architecture changes are too drastic.
No different from the problems facing the gcc team when supporting
code generators for new processors. They are presently at well over
20 architectures. And yes, some of the code generators suck.
> doing hand placement for critical circuits. When I switched from
> Virtex E to Virtex II not only was all of my work in Virtex E
> worthless, it was a hindrance
I doubt that "worthless". As ex-VirtexE-er you surely learned VirtexII
faster than someone with no experience in placing and so also no
knowledge what sort of pitfalls to look out for. Reuse of knowledge.
> > > Does not look like you are an average user there. :-)
> >
> > Actually, I think he is a typical user. I think every place I have
> > worked has used beta versions of the chips at one time or another.
> To be clearer, I am a typical Tier One user of FPGAs. Meaning that the
> companies I have worked for are high profile international accounts
> for the FPGA companies.
Your critique may apply to the situation at top commercial facilities.
For home/edu (where I am) I would not expect that to be the case.
> know that from a volume standpoint my group uses more FPGAs than any
> other group.
Present usage. Think a bit further into the future. There are millions
of future developers out there. Presently they are playing around
designing websites. What are they going to go into professionally?
Websites. Now think if a few 10'000 of them were playing around with
FPGAs. Whom will they be presenting their workforce to in 5 years?
> plentiful (no longer NDA) but this group would be limited and most
> likely restricted to hobbyists, students, and a few niche markets
> which have little competition.
And that is already usefull.
> You can choose to debate this, however, the fact such tools
> don’t exist is pretty good support for my argument.
Nope. Non-existance comes from non-information. Proof for your
argument will only be available after the information has been
available for some time and not being used.
--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery
Article: 37091Just to clarify: Virtex-E: XCV200E has 112 K bits of BlockRAM = 28 BlockRAMs Spartan-IIE: XC2S200E has 56 K of BlockRAM = 14 BlockRAMs. The data sheets say it all. Peter Alfke =================================== Damir Danijel Zagar wrote: > According to Spartan-IIE datasheet, both 200 parts have the same > amount of block ram (56k). > > Damir > > "Jan Gray" <jsgray@acm.org> wrote in message > news:9u3knp$53a$1@slb4.atl.mindspring.net... > > "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message > > news:3C0535D4.868C1E65@algor.co.uk... > > > o Do they relate to VirtexE's in the same way as SpartanII did to the > > > Virtex ? Esp wrt timing. > > > > http://fpgacpu.org/#011120: > > > > "You might think that > > > > as Virtex-E is to Virtex, so is Spartan-IIE to Spartan-II > > > > But you would be wrong. According to data sheets, whereas an XCV200 has 14 > > BRAMs (56 Kb) and the XCV200E has 28 BRAMs (112 Kb), in the Spartan-II/E > > family, both the XC2S200 and (alas) the XC2S200E have the same 14 BRAMs > (56 > > Kb). > > ... > > But let us count our blessings. The new Spartan-IIE family is > lower-voltage, > > faster (470 ps TILO (2SxxxE-6) vs. 700 ps TILO (2Sxxx-5)), offers a larger > > part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of > different > > I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208 > > QFP packages. " > > > > Jan Gray > > Gray Research LLC > > > > > >Article: 37092
Rick, Nope. The current is required before a gate knows what it is. All sub-threshold behavior before the logic wakes up. Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > Rick, > > > > Now we get into the 'voodoo' part of the analysis. > > > > With a number of devices in parallel the issue becomes complex. If each > > device requires a current based on the voltage it sees across its terminals, > > there is some small variation of this voltage to current behavior from die > > to die, part to part. There is also some IR drop in each package, and > > through the board. > > > > The text suggests that with four times the current, you will succeed, and > > discusses how more than four times is not required even though the peak > > current may exceed the minimum required. It does not imply you can use less > > than four times the specification. > > > > No one can say with any certainty that the four parts will power ON with > > less than four times the individual ratings, other than: we guard banded > > the spec (so the actual current is almost surely less), they won't all > > require the current at the exact same moment, any one device will have the > > total current available to it if the others are not using it yet (or have > > finished using it). > > > > Austin > > > > > > Is this current related in anyway to device configuration ? If there are > multiple Spartan devices on board would staggering the release of the PROGRAM* > pins help the situation ?Article: 37093
How about grabbing a palette chip off an old VGA board ? RobArticle: 37094
adrian wrote: > I'll tell you exactly what I need it for. I have designed an >FPGA based Pulsar timer for a radio astronomy observatory. >What the instrument essentially does is coherent averaging on >pulses coming from neutron stars (pulsars)to build up a pulse >profile. Averaging, right now, will take place over a maximum of >5 minutes, although this will probably be much less in the future. >I need to be able to set a user defined sampling frequency to >this resolution, and not have at move at all. If it does, it >means that the pulse will being to drift across the averaged >profile, and move around with jitter. Won't the jitter average out in the long run? I would expect long term stability to be a more important problem. Last I heard, pulsars were expected to be more accurate clocks than any earthbound clock. Are you trying to test that? -- glenArticle: 37095
Hi - If you aren't designing with Virtex-II, or don't check the timing of your FPGA designs, read no further. Xilinx has just posted to its web site some updated timing numbers for Virtex-II. A few things, such as the multipliers and some DCI drivers, seem to have slowed down compared to numbers published as recently as July, so you may want to take a look: http://www.xilinx.com/partinfo/ds031-3.pdf I haven't checked to see if these new numbers are reflected in 4.1 SP2. Obligatory disclaimer: Xilinx says these numbers--and those that appeared prevously--are advanced, so the change is no big surprise. I just thought folks might want to know. Bob Perlman Cambrian Design WorksArticle: 37096
olupas@opencores.org (Ovidiu Lupas) writes: >Hi all, >In my current project I have to implement scrambling and CRCs over a >128-bit data bus at a clock rate of 100 MHz. My combinatorial areas >are huge and I am having problems meeting the speed requirements. >Could someone give me an hint how to overcome this problem ? >Any hints will be appreciated. Well, I think the hint is pipelining. I think you can pipeline the CRC algorithm. Do you mean 12,800 Mbit/second? That is what 128 bit at 100MHz should mean. The traditional hardware CRC is bit serial, but the common software implementation is byte serial with a 256 entry lookup table. If you have 16 such tables and enough pipeline registers I think it can be done. -- glenArticle: 37097
On 28 Nov 2001 08:14:58 -0800, brad@tinyboot.com (Brad Eckert) wrote: >At a recent FPSLIC seminar, Atmel's marketing guy mentioned that some >FPGAs have high startup current (a couple of amps) so their FPSLIC >would have simpler power requirements than a soft CPU. > >Is this still true? I'm looking at a Spartan II XC2S30 or XC2S15 for a >soft CPU. Even a 1A startup current is a little hard to imagine, since >you'd expect the logic to start out in a cleared state. > >Can anyone tell me what kind of startup current to expect from low >cost FPGAs like Spartan or ACEX? In case anyone thinks this sort of behaviour is new, I recall seeing an app note in an Intel memory data book from almost 20 years ago that showed that their (then new) 5V only NMOS DRAM parts would draw lots of current when the supply voltage ramped up to about 1.5V (IIRC). The cause in that case was that the back bias generator for the substrate hadn't turned on yet, and the leakage current in each fet was rather large. The V-I characteristic was something like: ^I | | | . . | . . . | . . . | . . |. +------------------------>V Regards, Allan.Article: 37098
On Thu, 29 Nov 2001 21:15:04 +0000 (UTC), nweaver@CSUA.Berkeley.EDU
(Nicholas Weaver) wrote:
>In article <c2088d4a.0111290138.10577818@posting.google.com>,
>Ovidiu Lupas <olupas@opencores.org> wrote:
>>Hi all,
>>
>>In my current project I have to implement scrambling and CRCs over a
>>128-bit data bus at a clock rate of 100 MHz. My combinatorial areas
>>are huge and I am having problems meeting the speed requirements.
>>
>>Could someone give me an hint how to overcome this problem ?
>>Any hints will be appreciated.
>
>What exactly are your scrambling requirements?
One would guess that as 128 bits x 100MHz = 12.8Gbps, this would be
either RFC 2615 POS over OC192, or 10G Ethernet.
>From http://www.ietf.org/rfc/rfc2615.txt?number=2615
"4. X**43 + 1 Scrambler Description
The X**43 + 1 scrambler transmitter and receiver operation are as
follows:
Transmitter schematic:
Unscrambled Data
|
v
+-------------------------------------+ +---+
+->| --> 43 bit shift register --> |--->|xor|
| +-------------------------------------+ +---+
| |
+-----------------------------------------------+
|
v
Scrambled Data
"
Please note that this is the 'serial prototype' and doesn't look
anything like the parallel version that the OP requires.
>100 MHz should be no
>problem on a modern part, I have a Rijndael core I'm building in a
>Spartan II-5, it runs at >110 MHz.
I suspect that the OP could actually drop the clock rate to ~85MHz and
still meet the line rate requirements.
Regards,
Allan.
Article: 37099glen herrmannsfeldt wrote: > > olupas@opencores.org (Ovidiu Lupas) writes: > > >Hi all, > > >In my current project I have to implement scrambling and CRCs over a > >128-bit data bus at a clock rate of 100 MHz. My combinatorial areas > >are huge and I am having problems meeting the speed requirements. > > >Could someone give me an hint how to overcome this problem ? > >Any hints will be appreciated. > > Well, I think the hint is pipelining. I think you can pipeline > the CRC algorithm. > > Do you mean 12,800 Mbit/second? That is what 128 bit at 100MHz should > mean. The traditional hardware CRC is bit serial, but the common > software implementation is byte serial with a 256 entry lookup table. > If you have 16 such tables and enough pipeline registers I think > it can be done. > > -- glen Nice try, but you can't pipeline the full CRC calculation. Since the feedback term is needed from the full 128 bit register on every clock cycle, you can't pipeline the calc. If you try you don't have the full 128 bit feedback inputs until all 16 bytes have been processed. The CRC calculations always boil down to the XOR of a set of inputs and feedback signals, or consider this a single bit sum. You can separately sum the input signals and the feedback signals. Each output bit to be calculated will use about half of the inputs and half of the feedback bits. So you can use a pipeline to "precalculate" the input signals down to one bit. But the feedback bits always have to be done in one clock cycle. You might be able to optimize the speed by using the block ram as a wide fan-in XOR gate. Depends on the part you are targeting. There may also be a way to use the multipliers or adders in some FPGA families. A 32 bit adder can "modulo one count" the ones in a 32 bit word. Or two 16 bit adders halve the carry time and can be summed in one LUT. With a little hand tuning, you might be able to use the MSB LUT for this. I bet Ray A has a Viewlogic macro that already does this :) I bet this is a CRC-32 (or CRC-16) being done on an OC-192 at 10 Gbps. That is where I saw this done before. The initial signal is bit serial, but the payload is being processed in an FPGA at about 80 or so MHz in a 128 bit wide word. Just a guess. -- 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 FAX
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