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 Uwe, How can he control the speed at which the individual gates are switching? Are you suggesting he should make the inverter chain long to prevent the inverters from switching often or something else? Thanks, Ljubisa Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:<cgk5oq$m6m$1@lnx107.hrz.tu-darmstadt.de>... > Siva Velusamy <sv7d@adder.cs.virginia.edu> wrote: > > : Thanks everyone for the suggestions. > > : The problem was clearly due to difference in routing. Using FPGA Editor's > : directed routing, I obtained the routing information for one particular > : placement, and simply copied them over for all other instances only > : substituting the correct net names. Now all the frequencies are in a 2% > : range, far better than the 10% earlier. > > : Peter - Could you explain a bit more about how to use the carry chain? > : From the docs I could see that the carry chain goes up vertically through > : the slices, so I understand the part about automatic floorplanning - but > : how exactly should I configure them? There is no local connection between > : Cin and the CI/DI inputs. So I cannot directly send the carry signal as > : the select for the subsequent mux. Also, for this application I don't have > : any target frequency - I only need a predictable response with variation > : in temperature. So I probably don't need more stages. > > : Kevin - Yes, I am trying to measure the temperature over different parts > : of the die. Specifically I am interested in the temperature gradient. > : There have already been papers (in FPGA 04 for instance) that have shown > : that a gradient exists. > > Well, > > if you are interested into the thermal behaviour, you probably don't want to > run the stages of the ring oscillator at nearly full gate speed, as this > will contribute to (local) heating... > > ByeArticle: 72626
These options are nice, especially Read_First (Read before write). They might even help relative timing between ports, provided both ports use the same clock. But we do not guarantee this, since you would then rely on excellent timing tracking between adjacent ports of the BlockRAM circuitry. Peter Alfke> > Actually in the newer BlockRAM implementations, you can choose the > behaviour (at least you can on the Spartan-3, whose datasheets I've been > poring over recently :-) > > There's: > > o READ_FIRST, which will always report the value of the data > in RAM before the write was committed > > o WRITE_FIRST, which will provide the unpredictable behaviour > you mention (and it's the default, to provide backwards > compatibility) > > o NO_CHANGE, which seems to disconnect the output RAM so the > output value remains unchanged. > > I doubt anything would help you if you simultaneously write into the > same address on both ports, though :-) > > Simon.Article: 72627
Simon wrote: > Brian Philofsky wrote: > >> >> >> <snip> > > > Actually in the newer BlockRAM implementations, you can choose the > behaviour (at least you can on the Spartan-3, whose datasheets I've been > poring over recently :-) > > There's: > > o READ_FIRST, which will always report the value of the data > in RAM before the write was committed > > o WRITE_FIRST, which will provide the unpredictable behaviour > you mention (and it's the default, to provide backwards > compatibility) > > o NO_CHANGE, which seems to disconnect the output RAM so the > output value remains unchanged. > > I doubt anything would help you if you simultaneously write into the > same address on both ports, though :-) This is a mis-conception many fall into. Those modes apply only to the port that is being written to. In other words, the output of the port being written has this known behavior you specify above but as for the other port, everything I said still applies regardless of which mode you have it in. -- BrianArticle: 72628
>These options are nice, especially Read_First (Read before write). > They might even help relative timing between ports, provided both ports use >the same clock. But we do not guarantee this, since you would then rely on >excellent timing tracking between adjacent ports of the BlockRAM circuitry. Then there is skew in the clock distribution network(s). (Ugh. My head hurts.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 72629
The Xilinx DCM was originally supposed to have a spreading feature which would smear the output clock's spectrum to reduce EMI. There are some inputs on the DCM, called DSS_MODE and DSSEN, I think, that are for this feature. I wanted to use this feature recently and it seems to be unsupported. What happened? Does it not work? -KevinArticle: 72630
Brian Philofsky wrote: > If you are reading from one port of a RAM and > at the approximately same time writing to the other at the same address, > there is no tell whether the read data will be the old data, the new > data or something in-between. A controller is required to provide arbitration as it is for any shared resource. In a synchronous design, both sides use the same clock, and all is well. > Timing simulation also ensures your design is properly constrained and > nothing is missed during static timing analysis (is that path really a > multi-cycle path? Can you safely ignore timing on this path? A multi-cycle can be eliminated with adequate pipelining. > Did you miss anything? Not if all inputs are registered and all processes are synchronous. > Are you certain the synthesis tool > interpreted your code they way you think it did? I have never had a problem with the standard synchronous templates. I would run a few gate sims if I were validating a new synthesis tool or inference template. I do check the utilization report and the edif schematic viewer after each synthesis. > Were there delays in the code, Static timing would catch that. > missed items in the sensitivity list, No. Just reset and clk. > misconnnected components > or other things in the code to make it behaviorally simulate different > than it was implemented by synthesis? A bad wire will be picked up in the functional sim. The more you infer, the fewer wires you will have. > If you are prepared with your testbench to do timing simulations, in > general not too much time or overhead needs to be spent at this step and > at minimum it will be another check off the list of ensuring the design > is properly verified and all things have been considered. Certainly it is not hard to do, and it should be done at least once as a release check-off item. However, it should not be a part of the edit-sim-edit flow. > Many times it > will save far more time than is spent here especially if you do find an > issue such as above that can not be easily identified by other > verification methods. If a problem is found at the gate level, either a new design rule, or better enforcement is indicated. Thanks for the posting. -- Mike TreselerArticle: 72631
Hello all,
I am using a Xilinx Spartan II FPGA on a prototype PCI add-in card
as the PCI device attached to the bus. According to the Spartan II
data sheet it appears that 5V PCI compatible IOs are indeed instantiable
which was the very reason for going with a Spartan II in the first place.
However, after correlating the appropriate requirements from the PCI spec
with what is claimed in the Spartan II data sheet I am not 100% positive
about true 5V PCI compliancy without extra circuitry (namely clamping
diodes to the 5V rail) because the PCI spec requires that a device with-
stand AC worst case voltages of +11V down to -5.5V respectively while the
data sheet gives +7V down to -2V which more or less resembles only the
3.3V PCI AC requirements. Notice that I am concerned about the over
and under voltages during switching and not the DC or ``5V tolerance''
behaviour of the device.
So, has anyone experienced problems with using Spartan II FPGAs in
typical (read: off-the-shelf el cheapo PCs) 5V PCI environments ?
And while I am at it, should the PCI CLK signal ideally be routed to
one of the GCK{0|1|2|3} inputs with IBUFG_PCI33_5 instantiated ?
Am I wrong with the assumption that the the dedicated pins (/PROGRAM,
Done, M0, M1, M2, and CCLK) only allow a high level of Vccint ?
Any help is greatly appreciated.
Thanks and regards,
Christian Boehme
Article: 72632Hello all, I am evaluating the use of a Xilinx XC9572XL CPLD vs. standard logic hardware for the glue logic between a Spartan II FPGA and an on-board FLASH device used to store the configuration bit stream. This mainly follows the idea presented in XAPP079 only that the configuration mode will be Slave Parallel. Specifically, I found it impossible to calculate the overall propagation delay of the (ripple?) counter presented in the design which is needed to determine the maximum clock frequency fed to the FLASH address counter. I am looking for something similar to the CLB FF delay timings in the FPGA data sheets. Anyone know how to determine said delay without actually implementing and measuring it ? Thanks and regards, Christian BoehmeArticle: 72633
I'd like to thank everyone for their input on the subject. I also want=20 to make clear that the cores in my design that I've created myself are=20 thoroughly simulated and analyzed. However, the system includes some=20 cores from CoreGen as well (filters, CORDIC, DDS etc) and I find it hard = to create a meaningful input to simulate the whole system, and that is=20 when I use ChipScope to watch the behavior of the different parts. One question is still unanswered though, and I'd really appreciate some=20 input on this matter. How come that a system that synthesized perfectly=20 fine in ISE 6.1 also does that in ISE 6.2, but with a lower performance=20 (i.e. much more noise etc)? I have checkes all the coregen cores that I=20 utilize and they are all the same version. I have also checked my own=20 logic, and it seem to synthesize the same way, but still the result is=20 so much better using 6.1. Johan --=20 ----------------------------------------------- Johan Bernsp=E5ng, xjohbex@xfoix.se Embedded systems designer Swedish Defence Research Agency Please remove the x's in the email address if replying to me personally.Article: 72634
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0408260854.32175499@posting.google.com>... > muthusnv@yahoo.co.in (Muthu) wrote in message news:<4f8e807b.0408260230.2b5aaf74@posting.google.com>... > > Hi, > > > > In a timing simulation, Setup / Hold violation of Flip-Flop will > > result in value of 'x' at the output. Is that Right? > > Usually. > > > If so, how double synchronisation circuits work in timing simulation ? > > Won't it propagate x. ? > > See part 12.0 in this very good paper: > > http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf > > Cheers, > JonB Thank you all.. Regards, Muthu SArticle: 72635
Marcus Harnisch <marcus.harnisch@gmx.net> wrote in message news:<86fz69bmmg.fsf@dipsy.harnisch.local>... > Hi Andre, > > Don't get me wrong, but if you are trying to decypher the waves at the > SDRAM interface it would help if you'd know about some of the basics > of DDR SDRAMs. The "usual suspects" (Micron, Samsung, etc.) provide > good datasheets for download. JEDEC79x (x >= C) might be a little > dry but is certainly the most comprehensive source of information in > that respect. > > Good luck, > Marcus Hi Marcus, could you tell me where to find that JEDEC79x ? Thank you AndréArticle: 72636
Ljubisa Bajic <eternal_nan@yahoo.com> wrote: : Hi Uwe, : How can he control the speed at which the individual gates are : switching? Are you suggesting he should make the inverter chain long : to prevent the inverters from switching often or something else? The longer the chain, the less switching per inverter per time. Obvious he can control the spped of a single inverter... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 72637
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:mirXc.451$mZ2.46793@news02.tsnz.net... > Luiz Carlos wrote: > >>PS Also missing from this spin, is the fact that the cheapest > >>previous-generation MAX devices, are actually cheaper than the > >>cheapest MAX II devices. > >> ie the price per resource unit has declined, but the > >>minimum unit-cost step has actually increased, because they > >>pruned the two smallest offerings. > > > > > > Jim, > > > > Do you mean the 32 and 64 macrocells MAX1 devices are dead? > > Not yet, but they did not move forward a generation. > That means if you are starting a new design, you should look > carefully at vendors whose parts have moved forward recently. > Could it perhaps be simply that there are relatively few customers looking for Max 2 features in something as small as a 32 or 64 macrocell PLD, and thus the Max 1 convers that sector perfectly adequetly? Think about what changed with the Max 2 architecture - the Max 1 use a traditional CPLD architecture, which requires routing resources that scale badly with macrocell count, making large chips proportionally very expensive. The Max 2 uses more fpga-style routing, which does scale well, making large chips proportionally cheaper. Thus the Max 2 is suited to bigger cplds, while the Max 1 suits small ones. And what makes you think that Altera bringing out the Max 2 means they will stop making the Max 1? No doubt there will be little further development of the current Max 1 line - it's a mature product, doing a perfectly good job. The larger parts will become less popular as they are replaced by Max 2 in designs, but Altera is unlikely to pull out of the small pld market segment just because they've now got a better part for a different market segment. They are a business, and they are not stupid - as long as people want small cpld's, they'll keep making them. As to whether they will invest in making future generations of small plds which are faster, lower-power, etc. - we'll just have to wait and see. Note - I don't have any connection with Altera other than as a user, and I also think the "four times the density at half the price" slogan was a bit misleading. And it could be that Jim has some insider information that I don't have, but I think the suggestion that they will be dropping their small cplds just because they've got better big cplds sounds like pure FUD. > > And the 128 macrocells MAX1 is cheaper than the "198 macrocell" MAX2? > > The asymptope price mentioned for MAX II is $1.50, which is quite > a lot higher than the cheapest MAX1. > Thus if you have a smallish amount of logic, and want some of the MAX > II features, or even a reduction in power, but no increase in price, > then you are out of luck. > Altera has left that market sector behind, but MAX II WILL have a > significant impact on the biggest CPLDs. > > Fortunately in the 32/64 MCell area, there are still Xilinx, Lattice, > and Atmel, all with low power devices. > > My point was really that when marketing trumpet 'half the price' > that's not always the whole story :) > > -jg >Article: 72638
Brian Philofsky, Thank u for ur response..i made changes in my stimulus as u told stimuli : process begin wait for 20 ns; reset <= '1'; wait for 120 ns; reset <= '0'; wait; end process stimuli; and i made simulation once again but @180 ns the rising edge data '0' of d comes to q1 in same rising edge ..actually it shud come at falling edge.. it is correct in functional simulation... i am getting same wrong result even if I used IFFDDRSE primitive . can u check this plz.. thank u vinod Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<412E568B.9020503@no_xilinx_spam.com>... > Vinod, > > I would guess that the reason you are seeing a functional difference > would be due to the fact that you are not waiting until the global > set/reset signal to complete. For all Xilinx gate-level simulations, a > global set/reset pulse is generated for the first 100 ns of the design > to initialize all of the registers and simulate the effect for the GSR > signal in simulation. For the first 100 ns of the design, the registers > will be in reset and will not change value. If you hold off you > stimulus for the first 100 ns of simulation (keep your clock running and > initialize the inputs but just don't wiggle them yet), you will likely > see more correlation between your behavioral and post-translate simulation. > > Also, if you are desiring to have the DDR register pulled into the I/O > and use the dedicated resource, you should be instantiating the IFDDRRSE > in the design. The code you are creating will use two separate > registers but not the dedicated DDR registers in the I/O. > > > -- Brian > > > vinod wrote: > > > i am vinod..i got problem with ddr for virtex2 fpga. i have written > > code and did functional simulation everything is correct but after > > post translate simulation i am not getting same result. here is my > > code and testbench > > > > code: > > library ieee; > > use ieee.std_logic_1164.all; > > library UNISIM; > > use UNISIM.VCOMPONENTS.ALL; > > > > entity input_ddr is > > Port ( d : in std_logic; > > reset : in std_logic; > > clk : in std_logic; > > dataoutx : out std_logic; > > dataouty : out std_logic > > ); > > end input_ddr; > > > > architecture input_ddr_arch of input_ddr is > > > > > > signal q1, q2 : std_logic; > > > > > > > > begin > > > > > > > > > > process (clk,d,reset) > > begin > > > > if reset = '1' then > > q1 <= '0'; > > dataoutx <= '0'; > > > > elsif rising_edge(clk) then > > q1 <= d; > > dataoutx <= q1; > > end if; > > end process; > > > > process (clk,d,reset) > > begin > > if reset = '1' then > > q2 <= '0'; > > dataouty <= '0'; > > elsif falling_edge(clk) then > > q2 <= d; > > dataouty <= q2; > > end if; > > end process; > > > > > > > > end input_ddr_arch; > > > > testbench.... > > library ieee; > > use ieee.std_logic_1164.all; library ieee; > > use ieee.std_logic_1164.all; > > use ieee.numeric_std.all; > > use IEEE.STD_LOGIC_1164.ALL; > > use IEEE.STD_LOGIC_ARITH.ALL; > > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > library UNISIM; > > use UNISIM.VCOMPONENTS.ALL; > > > > entity tbddr is > > end entity tbddr; > > > > architecture test2 of tbddr is > > component input_ddr is > > Port ( d : in std_logic; > > reset : in std_logic; > > clk : in std_logic; > > dataoutx : out std_logic; > > dataouty : out std_logic > > ); > > end component ; > > > > > > component FDDRRSE is > > port ( > > > > Q : out STD_ULOGIC; > > C0 : IN STD_ULOGIC; > > C1 : IN STD_ULOGIC; > > CE :IN STD_ULOGIC; > > D0 : IN STD_ULOGIC; > > D1 : IN STD_ULOGIC; > > R :IN STD_ULOGIC ; > > S : IN STD_ULOGIC > > ); > > end component; > > > > > > > > signal risdatax,faldatax : std_ulogic; > > signal dataoutx,dataouty : std_logic; > > signal count : natural range 0 to 15; > > --signal cnt : natural range 0 to 40; > > signal ind : std_logic; > > signal S,R,cE :std_logic; > > > > signal data : std_ulogic_vector(15 downto 0):="1101000111010101"; > > signal data1 : std_ulogic_vector(15 downto 0):= "1001011100011100"; > > --signal data2: std_ulogic_vector(15 downto 0):= "0010100111001011"; > > signal clk,invclk, reset :std_logic; > > signal clk2 ,d : std_logic; > > begin > > > > --clk2 <= not clk; > > > > > > uut1: input_ddr > > port map ( > > d => d, > > clk => clk, > > reset => reset, > > dataoutx => dataoutx, > > dataouty => dataouty > > > > > > ); > > > > > > FDDRRSEx : FDDRRSE > > port map ( > > > > Q => d, > > C0 => clk, > > c1 => invclk, > > CE => ce, > > > > d0 => risdatax, > > d1 => faldatax, > > r => '0', > > s => '0' > > ); > > > > > > > > clock1 : process > > begin > > clk <= '1'; > > invclk <= '0'; > > wait for 10 ns; > > > > clk <= '0'; > > invclk <= '1'; > > wait for 10 ns; > > end process; > > > > stimuli : process > > begin > > wait for 20 ns; > > reset <= '1'; > > > > wait for 40 ns; > > reset <= '0'; > > > > > > > > wait; > > end process stimuli; > > > > process(clk,reset,ind) > > begin > > if reset = '1' then > > count <= 0; > > ce <= '0'; > > risdatax <= '0'; > > faldatax <= '0'; > > elsif clk'event and clk = '1' then > > > > ce <= '1'; > > risdatax <= data(count); > > faldatax <= data1(count); > > if count < 15 then > > count <= count+1; > > elsif count = 15 then > > count <= 0; > > end if; > > end if; > > > > end process; > > end test2; > > > > > > > > i have used FFDDRSE primitive in testbench for generating double data > > rate. > > > > i will be waiting for reply... > > > > thanks in advance > > byeArticle: 72639
Uwe Bonnes wrote: > Ljubisa Bajic <eternal_nan@yahoo.com> wrote: > : Hi Uwe, > > : How can he control the speed at which the individual gates are > : switching? Are you suggesting he should make the inverter chain long > : to prevent the inverters from switching often or something else? > > The longer the chain, the less switching per inverter per time. Obvious he > can control the spped of a single inverter... [can't] The effect may be more subtle than that. Switching power is Sigma(Fn x Cn) x Vcc^2, Fn reduces in proportion with chain count, but the Cn increases, so ignoring buffering effects the ring osc itself will be nominally constant power. The power density will decrease, as that power is spread over more die, and it is probably also a good idea to gate/enable the oscillator, to further minimise the self-heating effects. That effect could be used to actually measure the local hot-spot effects caused by low node counts, running very fast. The power to measure the Freq will be another cost, and again that will favour lower frequencies - until you consider gating, and obtaining a fixed resolution / unit time. Here, higher freqs use more power, but allow lower % GATE times for a given resolution/ms. -jgArticle: 72640
David Brown wrote: > "Jim Granville" <no.spam@designtools.co.nz> wrote in message >>>Jim, >>> >>>Do you mean the 32 and 64 macrocells MAX1 devices are dead? >> >> Not yet, but they did not move forward a generation. >>That means if you are starting a new design, you should look >>carefully at vendors whose parts have moved forward recently. >> > > > Could it perhaps be simply that there are relatively few customers looking > for Max 2 features in something as small as a 32 or 64 macrocell PLD, and > thus the Max 1 convers that sector perfectly adequetly? Think about what > changed with the Max 2 architecture - the Max 1 use a traditional CPLD > architecture, which requires routing resources that scale badly with > macrocell count, making large chips proportionally very expensive. The Max > 2 uses more fpga-style routing, which does scale well, making large chips > proportionally cheaper. Thus the Max 2 is suited to bigger cplds, while the > Max 1 suits small ones. > > And what makes you think that Altera bringing out the Max 2 means they will > stop making the Max 1? No doubt there will be little further development of > the current Max 1 line - it's a mature product, doing a perfectly good job. > The larger parts will become less popular as they are replaced by Max 2 in > designs, but Altera is unlikely to pull out of the small pld market segment > just because they've now got a better part for a different market segment. > They are a business, and they are not stupid - as long as people want small > cpld's, they'll keep making them. As to whether they will invest in making > future generations of small plds which are faster, lower-power, etc. - we'll > just have to wait and see. You can still buy EPROMs too, which are mature products doing a perfectly good job :) > Note - I don't have any connection with Altera other than as a user, and I > also think the "four times the density at half the price" slogan was a bit > misleading. And it could be that Jim has some insider information that I > don't have, but I think the suggestion that they will be dropping their > small cplds just because they've got better big cplds sounds like pure FUD. I did not say Altera are dropping the small cplds, merely noting that they did NOT move forward a generation. Others have moved their smaller cplds forward, to lower Icc and lower mA/MHz. If you already have a Max1 device designed in, sure, why change ? If you are doing a new design, that's very different, and the high Icc of the Max 1 families is looking 'old fashioned' against the other offerings. -jgArticle: 72641
I am using Modelsim XE II/Starter 5.7g to try and mdoel some ROM that I have instantiated using COREGEN. I have associated a .COE file with the ROM in COREGEN with the values that I would like. However I get an error message in Modelsim when I try to run the simulation saying "failed to open VHDL file "romvalues.mif" in rb mode". Does anyone know how I can set up the initial values in the ROM? Thanks very much Adam MorrisArticle: 72642
The first ever DSP & FPGA Resource Guide is now available at www.dspengineering.comArticle: 72643
Hi Friends, Minford Technology has Altera FPGA and CPLD downloader, it can replace Altera ByteBlaster II directly and work in AS mode, PS mode, JTAG mode. It supports all Altera FPGA, CPLD and configuration devices (EPC, EPCS1 and EPCS4). For more technical or ordering information, please visit us at www.minford.ca, we ship our products worldwide. Very low price compared with Altera ByteBlaster II(US$150) Sincerely, James Wang Minford Technology Inc. Tel: 1 (416) 953-8926 E-mail: info@minford.caArticle: 72644
FPGA Board Newsletter August 2004
BurchED - Making FPGA Prototyping Easy!
http://www.burched.biz
In this newsletter:
(1) Did you break your FPGA?
(2) New products
(3) New upgrade offers for current customers
(4) Reminder - please keep in touch
(5) User website spotlight for August
(1) Did you break your FPGA?
Great news, if you blew up your FPGA!
BurchED now offers replacement of the XC2S300E FPGA on
your board, and we will mail it back to you, all for free!
http://www.burched.biz/FreeStuff.html
(2) New Products
* Sydney-X1E:
Following on from the successful release of the
Sydney-X1 FPGA development system, BurchED has now
released the Sydney-X1E. While the Sydney-X1 is
a lower cost and compact system, the Sydney-X1E is
a more expandable system in a larger box, with
a "quick release" lid.
http://www.burched.biz/sydneyx1e.html
* A range of "Bulk Saver Packs":
Significant savings for quantity purchases.
Ideal for setting up University Laboratories.
http://www.burched.biz/BulkSaverPacks.html
(3) New upgrade offers for current customers
Great offers for owners of BurchED products.
An opportunity to get the latest boards and systems,
at special prices. Offers include upgrade to a Sydney-X1E.
http://www.burched.biz/UpgradeDeals.html
(4) Reminder - please keep in touch
Please remember, as a customer or user of BurchED products,
you are very welcome to email us at any time with questions,
comments, or for discussion. We are always interested to hear
about your latest projects and applications.
Drop us a line at tony@burched.com.au
(5) User website spotlight for August
Keith Howell, in Cambridge, England.
http://www.howell1964.freeserve.co.uk/logic/burched/fpga_devkit_b5.htm
Keith has been a valued customer of BurchED for many
years, and he is a guy with alot of great technical ideas.
His website provides a very interesting read, and
he is available for FPGA consulting work, so please
contact him if you require FPGA design services.
Article: 72645Well, Seems like I have to buy some EPM "SLC" packages. Now the question will be from where I can buy EPLDs in very less quantities? Arrow Electronics which is vendor of Altera ships them in more then 900. I need only couple of them and I can buy upto 20-25. Please let me know. Drew "Antti Lukats" <antti@case2000.com> wrote in message news:<cgklvf$9k9$03$1@news.t-online.com>... > "Drew" <dhruvish@gmail.com> wrote in message > news:ad2011c0.0408260441.39841b@posting.google.com... > > Hello guys, > > > > I am trying to Assign the Max Family EPLD - EPM7064 LC44-7 and run my > > compilation. But in the Assign Device I find EPM7064 SLC44-7. There > > are some significant differences between LC and SLC in terms of Max > > allowable freq, LCELL delay etc. Please let me know if anybody can > > find it in the Assign Device section. > > its not there! all the devices with no JTAG ISP are dropped from Quartus, > you need to use MAXPLUS ! > but you need a special programmer to program those old PLDs anyway, you can > not program them with byteblaster ! > > AnttiArticle: 72646
Helo Guys, I am sort of new to it. I need to buy some EPLD which can be socketed so that I can remove and put another one it it. The problem I am having is, looking solely by the device package name (PLCC, TQFP) I cant tell its socketed or not. How do I know which one is socketed simply by looking at the device name. Say, EPM3032ALC44-4 and EPM3032ATC44-4. Please let me know, DrewArticle: 72647
Kevin, No, it does not work. Basically it spread the spectrum by the FCC test method and reduced power by only 1.5 dB. Not enough to do anything. It was a case where I got too clever, and did not do an FFT during simulation. The feature makes the periods alternately longer and shorter (great for adding jitter to check to see if you have enough slack in your timing! 100, 200, up to 500 ps of jitter). Unfortunately the modulation frequency is 1/21 the clock frequency, which makes the modulation at too high a frequency to spread the spectrum. We do have an (internal)app note for really spreading the spectrum (better than 20 dB reduction in carrier). Ask your FAE about it. It uses one DCM as the master, tracking the clock. A second DCM is run in test mode as a tap controlled oscillator. The tap values of the first DCM are read out, and jammed into the second DCM. The second DCM is not phase or frequency locked, but does generate a spread spectrum clock. As a practical test (it looked too good to be true), I used a narrowband FM receceiver at 50.000 MHz, and was clearly able to get an S9 signal unspread, and could not break squelch when the spreading was enabled. The short term jitter added turns out to be relatively small (less than 200 ps p-p) as the modulation frequency is now very low (compared to the old every 21th clock). Basically, there is a low frequency 'wander' that is providing the spreading. Future products may bring back the feature (working) once we have a 'best' method for doing it in an all digital fashion (using the DCM). If you want more details, you may also just email me directly. Austin Kevin Neilson wrote: > The Xilinx DCM was originally supposed to have a spreading feature which > would smear the output clock's spectrum to reduce EMI. There are some > inputs on the DCM, called DSS_MODE and DSSEN, I think, that are for this > feature. I wanted to use this feature recently and it seems to be > unsupported. What happened? Does it not work? -Kevin > >Article: 72648
This is a multi-part message in MIME format. --------------090902040809040404000403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Modelsim needs a *.MIF file to know what is the ROM initialization in behavioral simulation. I am not sure if COREGEN creates one for you but I think so. Anyway, if you change the coe file you have to regenerate the CORE to be sure ISE take it into account. Find attached an example of a MIF file and COE file. I hope this helps. Vincent. Adam wrote: > I am using Modelsim XE II/Starter 5.7g to try and mdoel some ROM that I > have instantiated using COREGEN. > > I have associated a .COE file with the ROM in COREGEN with the values > that I would like. > > However I get an error message in Modelsim when I try to run the > simulation saying "failed to open VHDL file "romvalues.mif" in rb mode". > > Does anyone know how I can set up the initial values in the ROM? > > Thanks very much > > Adam Morris --------------090902040809040404000403 Content-Type: text/plain; name="instmem_core.mif" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="instmem_core.mif" 10001100010000010000000000000001 00000100011000010000000000000001 00000100011000110000000000000001 10000100011000110000000000000001 10000100011000110000000000000001 00010000100000010000000000000000 00010000100000010000000000000001 00010000100000000000000000000001 00010000100000000000000000000000 00010000100000000000000000000001 00010100101000010000000000000001 00010100101000000000000000000000 00010100101000010000000000000000 00010100101000000000000000000000 00010100101000000000000000000001 00011100110000010000000000000001 00011100110000010000000000000000 00011100110000010000000000000001 00011100110000000000000000000001 00011100110000010000000000000001 00011100110000000000000000000000 00011100110000010000000000000001 00100100000000100000000000000000 10100100000000110000001000000000 10100100000001000000010000000000 10100100000001010000011000000000 10100100000001100000100000000000 00100000111000000000000000000000 10100001000000000000001000000000 10100001001000000000010000000000 10100001010000000000011000000000 10100001011000000000100000000000 01001000000000010100011000000001 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 01010010000000000000000000000000 00000000000000000000000000000000 --------------090902040809040404000403 Content-Type: text/plain; name="instructions.coe" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="instructions.coe" memory_initialization_radix=2; memory_initialization_vector= 10001100010000010000000000000001, 00000100011000010000000000000001, 00000100011000110000000000000001, 10000100011000110000000000000001, 10000100011000110000000000000001, 00010000100000010000000000000000, 00010000100000010000000000000001, 00010000100000000000000000000001, 00010000100000000000000000000000, 00010000100000000000000000000001, 00010100101000010000000000000001, 00010100101000000000000000000000, 00010100101000010000000000000000, 00010100101000000000000000000000, 00010100101000000000000000000001, 00011100110000010000000000000001, 00011100110000010000000000000000, 00011100110000010000000000000001, 00011100110000000000000000000001, 00011100110000010000000000000001, 00011100110000000000000000000000, 00011100110000010000000000000001, 00100100000000100000000000000000, 10100100000000110000001000000000, 10100100000001000000010000000000, 10100100000001010000011000000000, 10100100000001100000100000000000, 00100000111000000000000000000000, 10100001000000000000001000000000, 10100001001000000000010000000000, 10100001010000000000011000000000, 10100001011000000000100000000000, 01001000000000010100011000000001, 00000000000000000000000000000000, 00000000000000000000000000000000, 00000000000000000000000000000000, 01010010000000000000000000000000, 00000000000000000000000000000000, 00000000000000000000000000000000; --------------090902040809040404000403--Article: 72649
Thanks to all who responded! I think I have a better picture of what's available now. -- Georgi "john jakson" <johnjakson@yahoo.com> wrote in message news:adb3971c.0408260622.6bc86a66@posting.google.com... > "Georgi Beloev" <gbH8SPAM@beloev.net> wrote in message news:<SYydnTMglL5u-7fcRVn-gw@megapath.net>... > > Hi, > > > > I'm looking for an inexpensive (up to $1000) development board with the > > following features: > > > > - Relatively fast DSP, e.g., Blackfin. > > - Mid-range Cyclone II or Spartan-3 FPGA. > > - At least 4 MB SDRAM. > > - Video in (CVBS and Y/C), digital video decoder. > > - Video out (CVBS and Y/C), digital video encoder. > > - The video decoder and encoder should be able to work simultaneously. > > > > A combination of boards, e.g., a DSP kit and a plug-in FPGA board can also > > work. Other DSPs and FPGAs than the ones mentioned above can also be > > considered. This is for doing research on video processing and video > > compression; I don't have more precise requirements yet. > > > > Thanks, > > -- Georgi > > Usual place to start is > > http://www.fpga-faq.com/FPGA_Boards.shtml > > Nallatech comes to mind but there are a few others that do DSP+FPGA too. > > Google <dsp fpga video boards> gives me plenty to start by > $1k is cutting it on the low side for some of these vendors. > > > > http://www.entegra.co.uk/c6416_pmc_fpga_dsp_quadia.htm > > http://www.nuhorizons.com/products/xilinx/DSP/index.html > > http://www.lyrtech.com/DSP-development/educational/index.php > > http://www.traquair.com/catalog/microline.products.html > > http://www.mangodsp.com/ > > http://www.hunteng.co.uk/solutions/imagesys.htm > > > and so on > > regards > > johnjakson_usa_com
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