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
Hi Eric,
Thanks for your response!
RTR might help me out. I'm stuck with using a single 133MHZ PCI-X only
bitstream, but I should be able to gate IDSELI with RTR to at least make my
device invisible when the bus is in PCI2.2 mode.
I ran a couple of simulations with the pcix_fast.v core but I'm seeing RTR
_always_ asserted, no matter what initialization pattern I put on the bus at
RST. Any idea what I'm doing wrong? The design and implementation guides for my
build (071) say that I should see this signal asserted when the core detects
that the wrong bitstream is loaded for the bus mode. I am not using the mode
forcing bits in the core's CFG register.
Thanks!
Mark
Eric Crabill wrote:
> Hi Mark,
>
> I hope you don't mind that I've taken the liberty to answer the
> questions of several others in this email.
>
> You raise a good question. The behavior you see in your system
> is certainly not what is recommended in the PCI-X Addendum in terms
> of system initialization. The PCI-X Addendum suggests that a
> system evaluate M66EN and PCIXCAP to determine the lowest common
> denominator of bus mode, and then use that information to reset
> the bus into a mode that is appropriate. Section 9.10, paragraph
> four, from PCI-X Addendum 1.0b says:
>
>
>>A PCI-X system provides a circuit for sensing the state of the
>>PCIXCAP pin (see Section 14).
>
>
> Perhaps your system does not provide or use this circuit for
> sensing the states of M66EN and PCIXCAP. That aside, what your
> system is doing should still work, but it requires your card
> support operation in PCI mode (which is actually required for
> a compliant design).
>
> With the PCI-X core, you have several implementation options:
>
> * bitstream for PCI, 33 MHz with PCI-X, 66 MHz
> * bitstream for PCI, 33 MHz
> * bitstream for PCI-X, 66 MHz
> * bitstream for PCI-X, 133 MHz
>
> These implementations require different speedgrades. You can
> consult the datasheet or implementation guide for details.
>
> The first option is good if you require moderate performance
> and you want the simplicity of a single bitstream design.
>
> If you require ultimate performance, some extra steps are
> required. You would need to generate a PCI-X 133 MHz bitstream
> in addition to a PCI 33 MHz bitstream (this does not require
> redesign of the user application, simply a synthesis and place
> and route with different options).
>
> Then, you need to perform run-time reconfigurations whenever
> the busmode changes. The core has an output, RTR, indicating
> the wrong bitstream is loaded. One way to implement this is
> with a small CPLD and two PROMs. I'm sure there are others.
>
> Mike Treseler wrote:
>
>
>>Consider getting source code.
>
>
> That is considerably more expensive than $18k. If you want to
> explore that avenue, you should contact your local FAE.
>
> Brannon King wrote:
>
>
>>One would think that for $18k you could get a core that would
>>run both PCI64 at 66Mhz and PCIX at 133MHz depending upon
>>availability.
>
>
> I think $18k is a great deal for what you get. If you prefer
> less expensive:
>
> http://h18000.www1.hp.com/products/servers/technology/pci-x-terms.html
>
> This one is free. However, there are hidden costs in compliance
> verification and implementation details. And, you don't get any
> support. It may give you the opportunity, though, to pare the
> logic down to the bare minimum for your application -- which often
> helps performance.
>
>
>>1) The core is a pain in the rear when it comes to passing timing
>>specs, and with a -4 chip the 133 is impossible
>
>
> For PCI at 33 MHz with our core, timing is a slam dunk. For PCI-X,
> at any frequency, the I/O timing is guaranteed if you use the parts
> and speedgrades listed in the datasheet (-4 is not among those...)
>
> The difficulty of the internal PERIOD constraint is a function of the
> core AND the user design, so it cannot be guaranteed. I do recognize
> that 133 MHz internal operation can be difficult.
>
>
>>2) the majority of RAID and multimedia cards run PCI64, including
>>Intel and Adaptec's own ZCR stuff, and as soon as you put in a ZCR
>>your whole bus will kick down to 66MHz rendering your board useless
>
>
> In order for this to happen, there would have to be two slots on a
> 133 MHz bus segment. The motherboards I have seen only have one
> slot on a 133 MHz bus segment. If you have specific motherboards
> that have two slots on a 133 MHz segment, it would be useful to me
> to know what brand/part number.
>
> This behavior is more likely to happen if you have a four slot PCI-X
> 66 MHz bus, and you plug in a mix of PCI-only and PCI-X cards. The
> bus does have to run at the lowest common denominator. If one card
> doesn't support PCI-X, the bus does have to run in PCI mode. And
> if you are using our core, it requires 33 MHz in PCI mode.
>
>
>>3) I have been unable to get one of Xilinx's controllers to
>>successfully hot swap. Has anyone else? I, like the poster,
>>have been unsuccessful in this.
>
>
> You should file a case with Xilinx Support so that someone can
> systematically debug the issue with you. Not knowing the failure
> mechanism, I can't speculate what might be the issue.
>
> Eric
Article: 64801On Tue, 13 Jan 2004 19:37:31 -0800, Jim Lewis <Jim@SynthWorks.com> wrote: > >>>>Experience indicates that even simple examples >>>>may produce different results on different >>>>LRM compliant simulators. >>> >>>My read on the LRM and simulation cycle says that >>>if two simulators execute your example differently, >>>one of them is not compliant. >>>Have you seen different results for a delta >>>cycle situation like this that was not a >>>simulator bug? >> >> >> I didn't think the VHDL LRM defined the order in which processes are >> executed. Can you point to the particular part of the LRM that says >> this? Without a defined order, different simulators may produce >> different results. > >It does not specify an order between processes >running. It does specify when signals get >updated vs. when processes get run. For any >given execution cycle, first all signals that >are scheduled to change on that cycle are >updated and then processes are run. > >Hence in your example, both clk2 and sig1 >get updated and then the process is run. >As a result, as modified, the two processes >simulate as if there is only one register. The naïve user would have expected two registers. I don't recall the exact code which simulated differently (it was three jobs ago, and wasn't my code), but the simulator vendors both assured us that their simulators were correct, and that this was the problem of the LRM. (Now that I think about it, Modelsim could have been doing some non-LRM compliant speedup (despite what was claimed), which hid the race. I'm fairly sure the other simulator was doing the right thing.) Regards, Allan.Article: 64803
Hi, I installed ISE6.1i on the Fedora-Core1. Set these after install. % export LD_ASSUME_KERNEL=2.4.1 % export DISPLAY=:0 % /mnt/cdrom/setup Regards.Article: 64804
Hal, To use EasyPath(tm) one has to have a stable design, or a set of stable designs (like 3 designs). If you want to upgrade designs in the field, then you might be in trouble, just as you point out. You are not 100% guaranteed to be in trouble, but the yield of a new untried pattern to a set of EasyPath product will not be 100%. It will not be less than about 90 or 95% either, based on our tests and research. For some that is acceptable. For others, not. In any event, "Hard-to-copy" offers no ability to change at all, so there is no comparison. There is a 100% guarantee of returning and replacing all parts and boards if there is a required change. If I am trying to manage my risks, 10% failure vs 100% failure is a big factor. Nothing is perfect, but we strive to get the best fit for the customer with our product offerings. Austin Hal Murray wrote: >>"Hard-to-copy" means that if you make a mistake, you are toast. It is >>inevitable that customers do not think of absolutely everything. The >>new architecture will also allow us to provide EasyPath(tm), which if >>the customer calls up (which has happened, and boy are they glad they >>went with Xilinx!), and says "I forgot an inverter" we just modify the >>test program, and they are back in business IMMEDIATELY, with only a >>small charge (perhaps very small) for the modified test program work >>that we have to do. No one else can do this, either! In fact, >>EasyPath(tm) can be done for a few images (bistreams) and still retain >>the savings. This fits it well with customers that wish to have single >>platforms that perform multiple functions (ie cellular basestations >>which are notorious for needing major changes every three months). > > > I don't understand that. I assume we are discussing saving $ by > only testing the parts of the chip that will be used rather than > the whole thing. > > If the base stations are changing every three months, are they just > switching between a small collection of choices that are known > ahead of time, or are they rolling out new features? > > If they are rolling out new features, then they are probably making > interesting changes to the FPGA code and probably would want the > fully tested version rather than the cheaper one that might not run > the new code. > > > I like the idea of saving money, but I've never worked on gear > that didn't get fixed/upgraded in the field. >Article: 64805
Dear all, I'm currently attempting to simulate the microblaze core, following the instructions given in the "EDK Microblaze Tutorial v3.2" from Xilinx. I'm using EDK v3.2 and ISE v5.2, with Modelsim XE v5.6e. I have also followed the instructions for compiling the behavioural model libraries exactly as specified. However,when I come to compile the .do file from my project in Modelsim, I get errors like # ERROR: C:/edk_libs/microblaze_v2_00_a/microblaze/_primary.dat(1): near ";":This version of compiler incompatible with library .dat file # ERROR: C:/edk_libs/microblaze_v2_00_a/microblaze/_primary.dat(1): syntax error # ERROR: C:/edk_libs/microblaze_v2_00_a/microblaze/_primary.dat: This version of compiler incompatible with library .dat file # ERROR: C:/edk_libs/microblaze_v2_00_a/microblaze/_primary.dat(1): syntax error # WARNING[1]: c:/code/vhdl/microblaze/hdl/microblaze_wrapper.vhd(536): No default binding for component: "microblaze". (No entity named "microblaze" was found) # ERROR: c:/code/vhdl/microblaze/hdl/microblaze_wrapper.vhd(539): VHDL Compiler exiting # ERROR: C:/Modeltech_xe_starter/win32xoem/vcom failed. Does anyone know what has happened here? How can this version of the compiler possibly be incompatible with the files that were generated by it?? Many thanks, Edward.Article: 64806
Which is a big problem if you are structurally instantiating inside a generate. VHDL lets you
use a generate to plunk down multiple instances, and you can use a function in the RLOC string
so that the instances are not placed atop one another. As far as I can tell, you still can't
do that with verilog2001.
Allan Herriman wrote:
> Verilog 2001 supports attributes. However, even in this latest
> version of the language, it still isn't possible to have an attribute
> whose value is a string that is a function of e.g. a genvar.
--
--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: 64807In the Virtex II User Guide (v1.6.1) on pg 200, it states ... DCI in Virtex-II Hardware DCI only works with certain single-ended and differential I/O standards. DCI supports the following Virtex-II standards: LVDCI, LVDCI_DV2, GTL_DCI, GTLP_DCI, HSTL_I_DCI, HSTL_II_DCI, HSTL_III_DCI, HSTL_IV_DCI, SSTL2_I_DCI, SSTL2_II_DCI, SSTL3_I_DCI, and SSTL3_II_DCI, LVDS_25, LVDSEXT_25, LVDS_33_DCI, LVDS_25_DCI, LVDSEXT_33_DCI , and LVDSEXT_25_DCI. Note the reference to LVDS_33_DCI! In several other places I have found it stated that if you use DCI with LVDS, then you must have Vcco = 2.5V, or it won't work correctly. I would like to try DCI with my Virtex II LVDS inputs with Vcco = 3.3V, and have it work correctly. Can this be done? Or is there a typo in the User's Guide.Article: 64808
Jim Lewis <Jim@SynthWorks.com> wrote in message news:<40032827.3070501@SynthWorks.com>... > My brain just blew a fuse when with the ironic statement: > "Verilog is a very simple language so it's easier for > the tools guys to get it right." ...and even simpler for lazy/inexperienced/"clever" coders to create heinous "designs." > VHDL never had race conditions and never will. As Janick points out in his book: Shared Variables. Not that anyone in his/her right mind would ever use them, of course :) -aArticle: 64809
Hi Mark,
> RTR might help me out. I'm stuck with using a single 133MHZ
> PCI-X only bitstream, but I should be able to gate IDSELI
> with RTR to at least make my device invisible when the bus
> is in PCI2.2 mode.
From a simulation point of view, this will work. However, you
will find a problem in the implementation. If you insert any
logic after the IBUF for IDSEL in the wrapper file, you will
prevent the IFD packing into the IOB. What you'll see when you
run PAR is that you won't be able to meet the input setup specs
for IDSEL.
I haven't tried this, but I think a workable solution for your
case would be to gate the LCK signal in the wrapper file. This
would, I believe, hold the core and the user logic (but not the
bus mode detection logic) in reset. I appologize for offering
a solution that I haven't tested, and I hope it won't take more
than a few minutes of your time to try out... If it doesn't
work, contact me privately and we can look at other options.
> I ran a couple of simulations with the pcix_fast.v core but I'm
> seeing RTR _always_ asserted, no matter what initialization
> pattern I put on the bus at RST. Any idea what I'm doing wrong?
> The design and implementation guides for my build (071) say that
> I should see this signal asserted when the core detects that the
> wrong bitstream is loaded for the bus mode. I am not using the mode
> forcing bits in the core's CFG register.
You do need to set the mode forcing bits in the cfg file. Let me
describe what I did to see the operation of RTR. I'm using the
"example design" in build_071, as delivered, with these changes:
1. In file test_tb.v, changed cfg_test_s.v to cfg_test_x.v
(this sets the mode forcing bits to PCI-X mode only...)
2. In file test_tb.v, changed pcix_core.v to pcix_fast.v
(this changes to the other netlist...)
3. In file test_tb.v, changed ../../src/xpci/pcix-lc.v to
../../src/wrap/pcix_lc_64xf.v (changed to correct wrapper
file...)
4. Set the library search paths to point to appropriate location.
When you run the simulation, the initial busmode pattern is for
64-bit PCI during RST# assertion. You will see RTR is asserted.
However, you shouldn't act on RTR while the user RST signal is
asserted, because you are basically watching the output of a
transparent latch. If there are transient conditions on the bus
mode pattern, you may see transient RTR behavior. After RST on
the user side is deasserted, the latch closes and RTR will be
stable with the correct information. You should then act on RTR.
The testbench sees that RTR is asserted, and skips the PCI mode
tests. It then resets the bus again, in 64-bit PCI-X during
RST# assertion. After this completes, you will see that RTR is
deasserted, as expected.
A side note, we are working to improve the RTR mechanism so that
it won't assert spuriously during reset.
Eric
Article: 64810I am writing a VHDL model of an old cypress PLD (CY7C331). Does anybody know of any programs which which generate equations from .jed files for this device? I have completed the translation by hand but am getting unexpected results and I cannot get any help from Cypress because they say the part is too old. If there are no programs which will do this a programmer's or user's manual for that chip would be extremely helpful. thanks johnArticle: 64811
Allan, did you get my email yesterday? I sent you a few screenshots. Anyway: 1. is fixed. 2. and 3. Looks like the way to meet the spec is to buy an isolation transformer and follow the apps notes, a good source seems to be http://www.pulseeng.com/, so it should be just a matter to buy these. 4., I did more experiments with a longer (30m) cable, and the results are surprisingly good. Reflection from a terminated cable (connected to an Ethernet switch) are low, even when driving directly from the FPGA. Putting 50ohms or 100ohms series resistors doesn't have much influence besides attenuating the incident signal. In all cases, I did not seem to experience any packet drops. Good luck. Jean "Jean Nicolle" <j.nicolle@sbcglobal.net> wrote in message news:BJWMb.9463$aX2.9427@newssvr27.news.prodigy.com... > Whoa, good, that's what I needed, a guy who knows a little more than I do > about the Analog Ethernet requirements. > I'll make the necessary updates on the site. > > I didn't try long cables, that probably explains it why I didn't run into > problems. Will do, and try with 120ohms resistors. > Thanks. > Jean > > "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in > message news:orb700t0u712oa3tri7b5ub9264vki9flf@4ax.com... > > On Tue, 13 Jan 2004 08:08:22 GMT, "Jean Nicolle" > > <j.nicolle@sbcglobal.net> wrote: > > > > >I've published a 4-steps "recipe" on how to send traffic. The experiment > > >should be easy to follow through. > > > > > >You need: > > >1. Any FPGA development board, with 2 free IOs and a 20 MHz clock. > > >2. A PC with an Ethernet card, and the TCP-IP stack installed. > > >3. Optionally, a network hub or switch. > > >No Ethernet interface chip required. > > > > > >The Verilog source code (about 150 lines) is published here > > >http://www.fpga4fun.com/10BASE-T0.html > > > > > >I'd be happy to hear how that works. > > >The code has been tested in two different networks, with different FPGA > > >boards from different vendors. > > > > > >I think the applications possible are pretty cool. > > >Have fun! > > >Jean > > > > Hi Jean, > > > > Some suggestions: > > > > 1. This web page http://www.fpga4fun.com/10BASE-T1.html > > mentions that the Ethernet standard is "IEEE 802.3ae-2002". That's > > the 10Gbps standard! I suggest you change this to "IEEE 802.3-2002 -- > > Section One". > > Here is the direct URL: > > http://standards.ieee.org/getieee802/download/802.3-2002_part1.pdf > > Chapter 14 (10Base-T) is the relevant part of that document. > > > > 2. There is no way your circuit will meet many of the Ethernet > > electrical requirements (section 14.3 in the spec). Whilst it may > > pass data, and be of great educational value, I think you really > > should have a statement on your website saying that this isn't > > Ethernet compliant, otherwise newbies will think that it really is > > Ethernet and start designing it into their own products. > > > > 3. You probably do need the transformers, otherwise the section > > 14.3.1.1 isolation requirements of 2400V (yes, that's 2.4 kV) are a > > little difficult to meet. > > The 1kV common mode surge requirments in 14.3.1.2.7 (transmit) and > > 14.3.1.3.6 (receive) may also be difficult to meet without a > > transformer. > > > > 4. The receiver may work better with a 120ohm (or so) resistor > > between the RD- and RD+ pins. This should give the receiver a better > > return loss (which is meant to be 15dB minimum, according to > > 14.3.1.3.4), and might improve the performance on long cables. > > > > > > BTW, what error rate did you get over 100m of cable? > > > > Regards, > > Allan. > >Article: 64812
Jean Nicolle <j.nicolle@sbcglobal.net> wrote: : Allan, did you get my email yesterday? I sent you a few screenshots. : Anyway: : 1. is fixed. : 2. and 3. : Looks like the way to meet the spec is to buy an isolation transformer and : follow the apps notes, a good source seems to be http://www.pulseeng.com/, : so it should be just a matter to buy these. An old 10 MBit card might be a good source for the transformer.. ... : > > 4. The receiver may work better with a 120ohm (or so) resistor ... Please don't fullquote. It only fills up the archive with redundancy... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 64813
Vaughn Betz wrote: > Rene Tschaggelar <none@none.none> wrote in message news:<41c489438e778508c6ca433ed9cabaf5@news.teranews.com>... > >>Browsing the 'cyclone device handbook' I spent a great >>length to find : >>-the max current for each supply ( VCCIO & VCCINT ) >>-the expected clocking frequency at the input. I'm aware >> that 1MHz may not be sufficient to PLL it up to 400MHz >> or such. >> >>to little avail. While I can live with 2 switchmode supplies >>generating 1.5V and 3.3V at 2A each, and a generic 8pin >>socket to swap oscillators for a prototype, the documentation >>is somehow inclomplete. > > Hi Rene, > > See section 4 of the Cyclone device handbook. (Available at > http://www.altera.com/literature/hb/cyc/cyc_c51004.pdf). Page 4-8 > gives the current & power during configuration, and refers you to the > Cyclone power calculator spreadsheet for doing what-if analysis on > application circuits power and current needs while they're running. Thanks. I saw the maximum configuration currents but found them not really usefull for a non-powersaving application. I admittedly only scanned the document for 'mA'. > > That spreadsheet is at: > http://www.altera.com/products/devices/cyclone/utilities/power_calculator/cyc-power_calculator.html > > You'll have to enter what you think are reasonable worst-case numbers > in terms of operating frequency, toggle rate, IO standards used etc. > to get the current supply info you need. Thanks. Neither really binding numbers as liability is denied, nor useable without Excel. I'll be warned. I'll start with a pcb prototype where some space is reserved for heatsink mounting holes plus some screw power terminals in case the 2A switcher comes to its limit. > > Page 4-31 of the device handbook gives the PLL frequency specs. The > input frequency has to be between 15.625 MHz and 464 MHz for the > fastest (-6) speed grade, and between 15.625 MHz and 387 MHz for the > slowest (-8) speed grade. See > http://www.altera.com/literature/hb/cyc/cyc_c51004.pdf for details. Thanks. These numbers somehow slipped me, even though I scanned the document for 'PLL'. Too many occurences of it, I guess. ReneArticle: 64814
Hal Murray wrote: > > >> I don't think anyone publishes a *max* current for FPGAs. This depends > >> greatly on the design and the clock speed. It even depends on the > >> loading on the IO lines. But one way you can set a ceiling is to figure > >> out the maximum dissipation the package can provide and assume that can > >> come from either of the two supplies. The may be very conservative, but > >> it will give you a *maximum*. > > Does that really get you a max? > > Suppose heat is the limiting factor on the FPGA, but I run it in > a pulse mode. It's active 10% of the time, but working real hard > when it's active. The length of the active burst can be long > enough to cause trouble for the power supply if it's only beefy > enough for the average. So then you know that this is the case and you will adjust the calculations accordingly, right?Article: 64815
Konrad Eisele wrote: > > For those that are interested. A not yet finished > synthesizable vhdl ARM model can be downloaded at: > http://www.tamaki.de/data/vhdl.tar.gz > Implemented as a Integer Unit in Gaisler Research's > Leon-Soc. > > Note: Because I do not really know the licensing > situation, download at your own risk. It would appear that there are patent issues associated with implementing a full ARM core. As you are likely aware, this was done once before and the end result is that the code was removed from the web and has not been seen since. I don't think ARM is going to come to you and try to squash you. But if you continue with this project, expect to hear from them, politely, but firmly. Or they may offer you a job :)Article: 64816
Jack wrote: > # [nios-gdb-server] accepting gdb connection > # [nios-gdb-server] connecting to OCI, ocibase 0x00920800 > # [nios-gdb-server] ...using byteblaster (altLPT1) > # [nios-gdb-server] mdi error: found 0 devices instead of 1 > # [nios-gdb-server] failed to connect Are you using the NIOS 3.0 or the NIOS 3.10 kit? I've seen this happen a lot with the 3.0 kit, a lot less with the 3.10. Altera is a bit vague about the reason though. Best regards, BenArticle: 64817
> Hal Murray wrote: >> I don't understand that. I assume we are discussing saving $ by >> only testing the parts of the chip that will be used rather than >> the whole thing. >> >> If the base stations are changing every three months, are they just >> switching between a small collection of choices that are known >> ahead of time, or are they rolling out new features? >> >> If they are rolling out new features, then they are probably making >> interesting changes to the FPGA code and probably would want the >> fully tested version rather than the cheaper one that might not run >> the new code. >> >> >> I like the idea of saving money, but I've never worked on gear >> that didn't get fixed/upgraded in the field. Austin Lesea wrote: > Hal, > > To use EasyPath(tm) one has to have a stable design, or a set of stable > designs (like 3 designs). If you want to upgrade designs in the field, > then you might be in trouble, just as you point out. > > You are not 100% guaranteed to be in trouble, but the yield of a new > untried pattern to a set of EasyPath product will not be 100%. It will > not be less than about 90 or 95% either, based on our tests and research. Is this 90-95% based on a complete new pattern, or some small respin of the known good design ? > > For some that is acceptable. For others, not. In any event, > "Hard-to-copy" offers no ability to change at all, so there is no > comparison. There is a 100% guarantee of returning and replacing all > parts and boards if there is a required change. > > If I am trying to manage my risks, 10% failure vs 100% failure is a big > factor. > > Nothing is perfect, but we strive to get the best fit for the customer > with our product offerings. > > Austin Interesting numbers. This does point to some usefull tool features : 1) Ability to reuse as much existing place/route in a change as possible ( even to the point of less optimum results ) 2) Ability to create multiple, seeded changes to a design. - ie if your design change can hold 98% of previous proven/tested place/route and give, say 3 version of the 2% 'fix', then in a expensive HW situation you could try these 3, and choose the one that works. 3) Ability to place idle-test-patterns, into spare resource areas, with a view to giving some test coverage. It's all more work, but does give a satistical method to reduce the non-zero chance of 'must change HW', esp if that HW change is very costly. Reminds me of a story I heard about the very first Russian embedded uC, (military) where production came serialised with a list of which opcodes did not work, and the designers task was to code around that list. (Intel tried a similar path with their Pentium a while ago :)! -jgArticle: 64818
john williams wrote: > I am writing a VHDL model of an old cypress PLD (CY7C331). Does > anybody know of any programs which which generate equations from .jed > files for this device? > > I have completed the translation by hand but am getting unexpected > results and I cannot get any help from Cypress because they say the > part is too old. If there are no programs which will do this a > programmer's or user's manual for that chip would be extremely > helpful. These older PLDs tend to be highly regular. Do you still have tool flow for the device ? - that can help confirm unsure FUSE mappings, by using some simple code-deltas. Also, either with that older tool flow (or even manually on a device programmer) you can generate device test patterns, which can also help confirm (with a working device) that 'what you think the logic is', does indeed pass the vector tests. -jgArticle: 64819
That posting suggested to deduce the max operating power backwards from the package thermal resistance. Do NOT do that ! Package choice is dominated by cost and price consideration, both on the part of the chip manufacturer and on the part of the user. To make the assumption "because it comes in this high thermal resistance package, it will never dissipate more than x Watts" is, excuse the word, silly. Most FPGAs these days can be melted down by a crazy (but legitimate) design running at an outrageous ( but legitimate) clock frequency. It's up to the user to keep the junction temperature within spec. All we manufacturers can do is give you the best analysis tools we can come up with... Peter Alfke, Xilinx ============================= Ralph Malph wrote: > But one way you can set a ceiling is to figure > out the maximum dissipation the package can provide and assume that can come from either of the two supplies. The may be very conservative, but > it will give you a *maximum*.Article: 64820
Thanks ??? for this advice ??? wrote: > Hi, May be you didn't compile libruary.... > > If you have ise 5.2 or over then #15338 in Xilinx support... > > You can find compxlib. > > I can't english...sorry ^^* > > Good luck...bye > > "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> wrote > in message news:4003e953$1@news.vsnet.ch... > >>Hi, >> >>I have some troubles simulating a clkdll primitive with modelsim. >> >>I included a clkdll mapping in my VHDL project to do a clk2x and clk4x. >>After synthesis, all is working fine about frequency value (I have a 40 >>- 80 - 160 MHz). >> >>But now I have to simulate all of this with the main design. >>BUT how can I simulate CLKDLL without body description of the unisim >>library. >> >>For now, I just did a new VHDL architecture for my CLKDLL. But are there >> a better solution for simulation! >> >>Best Regards, >>Laurent Gauch >> >> >>------------ And now a word from our sponsor ------------------ >>Do your users want the best web-email gateway? Don't let your >>customers drift off to free webmail services install your own >>web gateway! >>-- See http://netwinsite.com/sponsor/sponsor_webmail.htm ---- > > >Article: 64821
jim granville wrote: > john williams wrote: > >> I am writing a VHDL model of an old cypress PLD (CY7C331). Does >> anybody know of any programs which which generate equations from .jed >> files for this device? >> >> I have completed the translation by hand but am getting unexpected >> results and I cannot get any help from Cypress because they say the >> part is too old. If there are no programs which will do this a >> programmer's or user's manual for that chip would be extremely >> helpful. > > > These older PLDs tend to be highly regular. > Do you still have tool flow for the device ? - that can help > confirm unsure FUSE mappings, by using some simple code-deltas. > > Also, either with that older tool flow (or even manually on a device > programmer) you can generate device test patterns, which can also help > confirm (with a working device) that 'what you think the logic is', > does indeed pass the vector tests. > > -jg > If you know the specification of your old design, this will be better to re-write the VHDL source ... you will save many flops in the PLD. Test patterns for reversing your .jed will be too dangerous. Laurent www.amontec.comArticle: 64822
Jim, The coverage (?) of a completely new and different pattern is about 90 to 95%. That is just because about 90 to 95% of any FPGA is unused (really, just count the number of bits set to a '1'). The overlap of bits that change from one design to the next is probably so random, that there is not much use in trying to keep track. Austin jim granville wrote: > > Hal Murray wrote: > >> I don't understand that. I assume we are discussing saving $ by > >> only testing the parts of the chip that will be used rather than > >> the whole thing. > >> > >> If the base stations are changing every three months, are they just > >> switching between a small collection of choices that are known > >> ahead of time, or are they rolling out new features? > >> > >> If they are rolling out new features, then they are probably making > >> interesting changes to the FPGA code and probably would want the > >> fully tested version rather than the cheaper one that might not run > >> the new code. > >> > >> > >> I like the idea of saving money, but I've never worked on gear > >> that didn't get fixed/upgraded in the field. > Austin Lesea wrote: > >> Hal, >> >> To use EasyPath(tm) one has to have a stable design, or a set of >> stable designs (like 3 designs). If you want to upgrade designs in >> the field, then you might be in trouble, just as you point out. >> >> You are not 100% guaranteed to be in trouble, but the yield of a new >> untried pattern to a set of EasyPath product will not be 100%. It >> will not be less than about 90 or 95% either, based on our tests and >> research. > > > Is this 90-95% based on a complete new pattern, or some small respin of > the known good design ? > >> >> For some that is acceptable. For others, not. In any event, >> "Hard-to-copy" offers no ability to change at all, so there is no >> comparison. There is a 100% guarantee of returning and replacing all >> parts and boards if there is a required change. >> >> If I am trying to manage my risks, 10% failure vs 100% failure is a >> big factor. >> >> Nothing is perfect, but we strive to get the best fit for the customer >> with our product offerings. >> >> Austin > > > Interesting numbers. > This does point to some usefull tool features : > 1) Ability to reuse as much existing place/route in a change as possible > ( even to the point of less optimum results ) > 2) Ability to create multiple, seeded changes to a design. > - ie if your design change can hold 98% of previous proven/tested > place/route and give, say 3 version of the 2% 'fix', then in a expensive > HW situation you could try these 3, and choose the one that works. > 3) Ability to place idle-test-patterns, into spare resource areas, with > a view to giving some test coverage. > > It's all more work, but does give a satistical method to reduce the > non-zero chance of 'must change HW', esp if that HW change is very costly. > > Reminds me of a story I heard about the very first Russian embedded uC, > (military) where production came serialised with a list of which opcodes > did not work, and the designers task was to code around that list. > (Intel tried a similar path with their Pentium a while ago :)! > -jg > >Article: 64823
Peter Alfke wrote: > That posting suggested to deduce the max operating power backwards from > the package thermal resistance. > Do NOT do that ! > Package choice is dominated by cost and price consideration, both on the > part of the chip manufacturer and on the part of the user. > To make the assumption "because it comes in this high thermal resistance > package, it will never dissipate more than x Watts" is, excuse the > word, silly. > Most FPGAs these days can be melted down by a crazy (but legitimate) > design running at an outrageous ( but legitimate) clock frequency. > It's up to the user to keep the junction temperature within spec. All we > manufacturers can do is give you the best analysis tools we can come up with... Thanks Peter, the first sensible answer. What is wrong with a simple formula ? Eg Imax = Io + 4mA/Mhz + I/O_load. It'd help specifying the power supply as well as the heatsink. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 64824
Does Altera have devices with I/O that can drive (or be driven) at 300 to 400MHz? Internal logic would have to run at 1/2 that frequency. RLDRAM II is the application. Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"
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