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, It is intersting to find that $24.50 is for an Altera ByteBlast programmer mentioned in a topics in FPGA group. I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chip only. Please give any tips where I can buy a cheap programmer. Thank you. WengArticle: 138451
On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > It is intersting to find that $24.50 is for an Altera ByteBlast > programmer mentioned in a topics in FPGA group. > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chip > only. > > Please give any tips where I can buy a cheap programmer. > > Thank you. > > Weng Digilent (digilentinc.com) has inexpensive programming cables. -Dave PollumArticle: 138452
On Feb 20, 8:24=A0pm, "Michael Brown" <s...@signature.below> wrote: > Note: Since Optus can't figure out how to run a Newsgroup server, the > original post hasn't appeared for me ... > > > Marty Ryba wrote innews:vQHnl.665$Ez6.422@nwrddc02.gnilink.net: > > >> Hi gang, > > >> =A0 =A0 I have an idea for a tweak of my FPGA design that involves > >> =A0 =A0 essentially > >> building a time interval counter. I found that there are some IP cores > >> out there that get as much as 100ps resolution, but before I go that > >> route I want to experiment with something "free" first, especially > >> since I don't need any bells and whistles like embedded bus protocols > >> or programmable timers. > > What sort of resolution and dead time do you need? If you're willing to d= o a > bit of legwork with manual place'n'route, and consume a fair bit of > resources, you can get in the order of 10 ps or so resolution and accurac= y > at the cost of 10's of nanoseconds of dead time. See:http://www-ppd.fnal.= gov/EEDOffice-W/Projects/ckm/comadc/WaveletTDC.ppt > They use an Altera Cyclone II, but I've implemented a similar thing on a > Spartan 3E with reasonable success. I don't have good enough testing > apparatus to properly measure the resolution and accuracy though. And at = the > 10 ps level, you've got to think a bit about what's on the outside of the > FPGA too ... > > The main downside to the Xilinx parts for this purpose is that you've onl= y > got 4 elements on the carry chain per block, as opposed to 8 in the Alter= a. > You can also tweak out the dead time by throwing more resources at it > (basically loop the end of the carry chain around to the start where it x= ors > with the input, then do edge detection along the whole buffer and track t= he > edges). Of course, this is so far beyond the point of "supported" that us= ing > it in a commercial project is debatable, but it's certainly a fun thing t= o > play with. > > -- > Michael Brown > Add michael@ to emboss.co.nz ---+--- My inbox is always open Michael - Would you be willing to share your design? I'm curious to see what is involved. John ProvidenzaArticle: 138453
Hi, I would like to know if I have an output pin on a spartan 3E FPGA that is changing between 1 and 0 with a period of 25 ns. What is the settling time of the transition if I use SLOW SLEW RATE vs FAST SLEW RATE. Thanks, AmishArticle: 138454
On Feb 23, 12:51=A0pm, emeb <ebromba...@gmail.com> wrote: > On Feb 23, 10:34=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > It's also worth sometimes putting in a few extra clock edges at the > > end. Also watch the LED on as it may clamp DONE low enough not be seen > > as a high. > > Yes, after I finish sending the bitstream data I continue to provide > CCLK transitions while holding DIN high. During this time my firmware > watches both the INIT and DONE lines - neither of them changes state. > The DONE LED never comes on either, so it's not an issue of the logic > level not registering a '1' either. > > When I configure it via JTAG the DONE LED does light up and the > voltage on the DONE line is about 1.9V (it's a blue LED). The MCU > specs a min Vih of 2.0V, so this might be an issue once I get that LED > to turn on though. > > Thanks, > > Eric Just remembered the problem that bit me in the past... Make sure that you shift out the bits in the right order. As I recall, MSB first when using a .bit file directly, but some other formats do bit order reversal by default requiring LSB-first shift. You would think that shifting bits in the wrong order would result in a CRC error which would force INIT back low. However sometimes you will never see this because the preamble required for the device to start shifting in the bitstream will also be scrambled and therefore you never get to the CRC checking phase. Regards, GaborArticle: 138455
sounds good, will give it a crackArticle: 138456
On Feb 23, 3:58=A0pm, gabor <ga...@alacron.com> wrote: > Just remembered the problem that bit me in the past... > Make sure that you shift out the bits in the right order. > As I recall, MSB first when using a .bit file directly, > but some other formats do bit order reversal by default > requiring LSB-first shift. =A0You would think that shifting > bits in the wrong order would result in a CRC error > which would force INIT back low. =A0However sometimes > you will never see this because the preamble required > for the device to start shifting in the bitstream > will also be scrambled and therefore you never get > to the CRC checking phase. I'm thinking along the same lines. Although I am using a .bit file and sending the data MSB first, I haven't yet ruled out a mal-formed preamble. That would prevent the loading state machine from even entering the phase where it starts checking CRCs. Back at the beginning of the debugging process I tried sending LSB first just as a check but that made no apparent difference. I should probably try that again now that I've tweaked a bunch of other stuff. I'm also continuing to check out my serializer algorithm in a test environment against some known-good sources. Failing that, I may end up building a logic analyzer with Chipscope and an FPGA development board... Thanks for the suggestions... EricArticle: 138457
On Feb 23, 12:42=A0pm, Dave Pollum <vze24...@verizon.net> wrote: > On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > Hi, > > It is intersting to find that $24.50 is for an Altera ByteBlast > > programmer mentioned in a topics in FPGA group. > > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chip > > only. > > > Please give any tips where I can buy a cheap programmer. > > > Thank you. > > > Weng > > Digilent (digilentinc.com) has inexpensive programming cables. > -Dave Pollum Hi Dave, Good information! I need cables too. But hopefully I may get a set of programmer plus its cables from one person or a company. WengArticle: 138458
"Bert" <bert.pieters@gmail.com> wrote in message news:7ade16c9-6fa6-4d62-b15f-59a2d5f4d267@p29g2000vbn.googlegroups.com... > Hi all, > > to cover the needs of my application, I wish to generate from a 50 MHz > crystal attached to my cyclone2 fpga (EP2C35) the four phase (0, 90, > 180 and 270 degrees) at 60 MHz. > > I tried to cascade 2 PLL: > - one PLL to generate 60 MHz from the crystal, > - one PLL to generate 90, 180 and 270 degrees from the previously > generated 60 MHz clock. > > Quartus2 complaints that the input clock for the second PLL "must be > driven by a non-inverted input clock pin". So I guess PLL macros > cannot be cascaded. > > How could I resolve this issue? Has anyone a better design? > You can generate all four outputs from a single PLL. KJArticle: 138459
On Feb 23, 6:24=A0pm, emeb <ebromba...@gmail.com> wrote: > On Feb 23, 3:58=A0pm, gabor <ga...@alacron.com> wrote: > > > Just remembered the problem that bit me in the past... > > Make sure that you shift out the bits in the right order. > > As I recall, MSB first when using a .bit file directly, > > but some other formats do bit order reversal by default > > requiring LSB-first shift. =A0You would think that shifting > > bits in the wrong order would result in a CRC error > > which would force INIT back low. =A0However sometimes > > you will never see this because the preamble required > > for the device to start shifting in the bitstream > > will also be scrambled and therefore you never get > > to the CRC checking phase. > > I'm thinking along the same lines. Although I am using a .bit file and > sending the data MSB first, I haven't yet ruled out a mal-formed > preamble. That would prevent the loading state machine from even > entering the phase where it starts checking CRCs. Back at the > beginning of the debugging process I tried sending LSB first just as a > check but that made no apparent difference. I should probably try that > again now that I've tweaked a bunch of other stuff. I'm also > continuing to check out my serializer algorithm in a test environment > against some known-good sources. Failing that, I may end up building a > logic analyzer with Chipscope and an FPGA development board... > > Thanks for the suggestions... > > Eric Any change in GTS_, GWE, GHIGH (status reg) after you make a programming attempt? Those bits may give you a clue to where it fails. I also think the way you have your DONE LED is a bit sketchy, but if it works over JTAG then that shouldn't be the issue. Cheers, MikeArticle: 138460
On Feb 23, 6:44=A0pm, mng <michael.jh...@gmail.com> wrote: > Any change in GTS_, GWE, GHIGH (status reg) after you make a > programming attempt? Those bits may give you a clue to where it fails. > I also think the way you have your DONE LED is a bit sketchy, but if > it works over JTAG then that shouldn't be the issue. Thanks to all for the helpful suggestions. I've gotten it working now. The problem was that the embedded filesystem read function didn't like the way I was using it (sensitive to odd buffer sizes) and was handing my parsing routine bogus data which corrupted the bitstream going out to the FPGA. I re-wrote my parser to only read 512-byte buffers and now it works just fine. EricArticle: 138461
"-jg" <Jim.Granville@gmail.com> wrote in message news:0693be8d-4e0b-4fe9-8274-94ca2995567c@n33g2000pri.googlegroups.com... On Feb 21, 1:23 pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > > I have an idea for a tweak of my FPGA design that involves essentially > > building a time interval counter. I found that there are some IP cores > > out > > there that get as much as 100ps resolution, but before I go that route I > > want to experiment with something "free" first, especially since I don't > > need any bells and whistles like embedded bus protocols or programmable > > timers. Neither of the signals I want to time between are synchronous > > with > > my main clock > Your title says fast counter, but the text says time interval. > They are not quite the same thing. > If you want to do precise interval timing, then multi-phase capture, > and/or > delay line capture will give you time-domain precisions above the > clock frequency. > What time-precision do you actually need ? > eg 250MHz with 4 phases, resolves to 1ns Thanks for the useful tips; it seems the primary approach is to "stretch" the signals of interest into fast elements like shift registers and/or carry chains, and then count these up at some leisure later (how?). That sounds like it takes a lot of resources (e.g., 16 ticks per slice if I use a SRL16E). This could explain why some of the papers I've glanced at seem to take pretty much an entire chip to make a couple of these high-end delay measuring devices. For now, since it seems feasible to run a small (8 bit) counter at 204.8 MHz, I'll try that route. 4.883 ns of precision is about 1.5 meters when you multiply by c, so that's still useful to me. Once I get the basic structure figured out I can look at speeding it up. Today I got the input logic figured out (what signal is my start condition, and what is my stop). Since I'm using these signals to calibrate out differences between identical bitstreams on separated boards inside a common chassis, the differential delays inside the logic should mostly wash out. One "newbie" question: I notice you can't use an output pin signal to drive internal logic (at least Modelsim barfs on it). I ended up for now declaring a signal and copying some of the code that generates that output pin to generate my signal as well. Is there a "smarter" way? Thanks again, MartyArticle: 138462
Marty Ryba wrote:
> "-jg" <Jim.Granville@gmail.com> wrote in message
> news:0693be8d-4e0b-4fe9-8274-94ca2995567c@n33g2000pri.googlegroups.com...
> On Feb 21, 1:23 pm, "Marty Ryba" <martin.ryba.nos...@verizon.net>
> wrote:
>> > I have an idea for a tweak of my FPGA design that involves essentially
>> > building a time interval counter. I found that there are some IP cores
>> > out
>> > there that get as much as 100ps resolution, but before I go that route
>> > I want to experiment with something "free" first, especially since I
>> > don't need any bells and whistles like embedded bus protocols or
>> > programmable timers. Neither of the signals I want to time between are
>> > synchronous with
>> > my main clock
>> Your title says fast counter, but the text says time interval.
>> They are not quite the same thing.
>> If you want to do precise interval timing, then multi-phase capture,
>> and/or
>> delay line capture will give you time-domain precisions above the
>> clock frequency.
>> What time-precision do you actually need ?
>> eg 250MHz with 4 phases, resolves to 1ns
>
> Thanks for the useful tips; it seems the primary approach is to "stretch"
> the signals of interest into fast elements like shift registers and/or
> carry chains, and then count these up at some leisure later (how?). That
> sounds like it takes a lot of resources (e.g., 16 ticks per slice if I use
> a SRL16E). This could explain why some of the papers I've glanced at seem
> to take pretty much an entire chip to make a couple of these high-end
> delay measuring devices. For now, since it seems feasible to run a small
> (8 bit) counter at 204.8 MHz, I'll try that route. 4.883 ns of precision
> is about 1.5 meters when you multiply by c, so that's still useful to me.
> Once I get the basic structure figured out I can look at speeding it up.
> Today I got the input logic figured out (what signal is my start
> condition, and what is my stop). Since I'm using these signals to
> calibrate out differences between identical bitstreams on separated boards
> inside a common chassis, the differential delays inside the logic should
> mostly wash out.
>
> One "newbie" question: I notice you can't use an output pin signal to
> drive internal logic (at least Modelsim barfs on it). I ended up for now
> declaring a signal and copying some of the code that generates that output
> pin to generate my signal as well. Is there a "smarter" way?
You shouldn't need to duplicate an logic; just create an intermediate signal.
For example this code would fail:
ENTITY divider IS
PORT
(
clk : IN STD_LOGIC;
div : OUT STD_LOGIC
);
END divider;
ARCHITECTURE model OF top IS
BEGIN
PROCES (clk)
BEGIN
IF (clk'EVENT) and (clk = '1') THEN
div <= NOT div;
END IF;
END PROCESS;
END;
But can be fixed by using an intermediate signal:
ENTITY divider IS
PORT
(
clk : IN STD_LOGIC;
div_o : OUT STD_LOGIC
);
END divider;
ARCHITECTURE model OF top IS
SIGNAL div : STD_LOGIC;
BEGIN
PROCES (clk)
BEGIN
IF (clk'EVENT) and (clk = '1') THEN
div <= NOT div;
END IF;
END PROCESS;
div_o <= div;
END;
Ken
>
> Thanks again,
>
> Marty
Article: 138463Has anyone tried an Opencores DDR controller? I am looking to run the DDR on the Spartan 3E board. Requirements: Open source (or at least no license needed) High speed is not required. (10MHz might be fine, maybe less.) Small would be nice. Self refresh isn't required, but might be nice. (Sometimes I might run a video display, which I presume if I do right will also refresh the DRAM.) -- glenArticle: 138464
Hi all, I'm trying to add a library to my project but I don't know the way to do it... I never did this operation before and I don't know what files I must create, in which location I must put them and how I must set the compiler options... Please could anyone tell me step by step how must I do? (the lib will contain few functions that I will use as a subroutines) thanks a lot... DanieleArticle: 138465
Hi all, I'm trying to add a library to my project but I don't know the way to do it... I never did this operation before and I don't know what files I must create, in which location I must put them and how I must set the compiler options... Please could anyone tell me step by step how must I do? (the lib will contain few functions that I will use as a subroutines) thanks a lot... DanieleArticle: 138466
Weng Tianxiang skrev: > Hi, > It is intersting to find that $24.50 is for an Altera ByteBlast > programmer mentioned in a topics in FPGA group. > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chip > only. > > Please give any tips where I can buy a cheap programmer. > > Thank you. > > Weng This one perhaps: http://www.morphologic.dk/shop/product_info.php?products_id=28 FinnArticle: 138467
Hi, I always seem to come up against systems that have some sort of cpu (I'm talking about a real cpu here, not a core in an FPGA) that has to configure some sort of FPGA. Solutions in the past have involved ugliness with CPLDs, Flash memories, parallel local buses, etc. The newer embedded processors seem to be favouring PCIe over the other types of interfaces. E.g. (just an example; I'm not actually going to use one of these any time soon) the Intel Atom (or its support chip) has 2 x PCIe, several x USB, I2C, but no simple local bus (just PATA). It looks like my future designs will need to configure FPGAs through a PCIe bus. The current generation of FPGAs might have PCIe support, but as yet, none offer any sort of configuration via PCIe. So far, it seems the best way is (despite the FPGA on-board transceivers) is to use a PCIe to local bus bridge chip from PLX or Gennum. I guess my questions are: 1. Is my take on the future of PCIe right? Will it become the only high speed interface in future mid- or high-level embedded CPUs? 2. Will future generations FPGAs be able to be programmed via PCIe? If so, when? 3. Is there a better way of configuring a current generation (e.g. V5 or V6) FPGA than via a bridge chip? Thanks, AllanArticle: 138468
Hi Glen, you can use the MIG Core from Xilinx Core Generator. This core comes with webpack of ISE. regards, MatthiasArticle: 138469
Hi, I'm using EDK 10.1 with SP3 and ISE 10.1 with SP3 I generated a FIFO in ISE to use it in an EDK design. It is a 64 bit wide and 512 deep FIFO. The fifo is created and implemented as ngc. The simulation show the behaviour as expected, but in the actual implementation in the FPGA it looks like the FIFO is full of zeros after reset. After all zeros are read out of the fifo normal behaviour starts again. I hope someone can help me with this. Thanks SebastianArticle: 138470
google@kleinmatze.de wrote: > you can use the MIG Core from Xilinx Core Generator. This core comes > with webpack of ISE. I will probably try that first, but it does seem to have restrictions on its licensing. I don't believe that I can redistribute the project code. -- glenArticle: 138471
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... > Hi, > > I guess my questions are: > > 2. Will future generations FPGAs be able to be programmed via PCIe? If > so, when? > Now? ;) Just need to use some external components to tie it together...or use partial reconfiguration (PR) flow. > 3. Is there a better way of configuring a current generation (e.g. V5 or > V6) FPGA than via a bridge chip? In our setup we're using ml555 and V5 internal pcie endpoint in order to perform PR of the reconfigurable core connected to one of the BARs. We're still in the early development stage,so its's hard to judge if its any better, but it works. Regards, Krzysztof KepaArticle: 138472
"Krzysztof Kepa" <nospam_blondikk@poczta.fm> wrote in news:go0pr0$6jj$1@aioe.org: > > "Allan Herriman" <allanherriman@hotmail.com> wrote in message > news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... >> Hi, >> >> I guess my questions are: >> >> 2. Will future generations FPGAs be able to be programmed via PCIe? >> If so, when? >> > Now? ;) Just need to use some external components to tie it > together...or use partial reconfiguration (PR) flow. I meant "gluelessly". With PR, one must get the original configuration into the FPGA somehow, and (as I understand it) that cannot be done with PCIe. Thanks for your comments. AllanArticle: 138473
On Feb 23, 12:35=A0pm, My Name <myemail@a_domain.com> wrote: > I Am a postgraduate student an my thesis subject is an implement of an > fm digital demodulator.I have already implement a digital down converter > with I and Q base band signals =A0in 2 complement format.Has anyone an > idea about how i can achieve demodulation with these two base band > signals.I use a cyclone III altera FPGA. > > -- > xristos > ------------------------------------------------------------------------ > xristos's Profile:http://www.fpgacentral.com/group/member.php?userid=3D15 > View this thread:http://www.fpgacentral.com/group/showthread.php?t=3D8811= 2 What you want to do is recover the frequency from I & Q. The phase is phi=3Datan(Q/I). The frequency is the time-derivative of the phase: dphi/ dt =3D d/dt (atan(Q/I)) =3D (Q * dI/dt - I dQ/dt) / (I^2 + Q^2). [That last relation is from memory; you should verify by deriving yourself.] With FM, you usually don't care about amplitude (it's a continuous- wave modulation; there is no information in the amplitude), so you might be able to simplify by just computing Q*dI/dt - I*dQ/dt. -- Poojan Wagh http://www.circuitdesign.info/blogArticle: 138474
OK, meanwhile I solved it. I didn't know that the fifo still accepts the write enable, even if reset is high. This cause filling up the fifo with zeros during reset. Sebastian On 24 Feb., 12:59, sebs <sebastian.schuep...@googlemail.com> wrote: > Hi, > > I'm using EDK 10.1 with SP3 and ISE 10.1 =A0with SP3 > > I generated a FIFO in ISE to use it in an EDK design. It is a 64 bit > wide and 512 deep FIFO. The fifo is created and implemented as ngc. > The simulation show the behaviour as expected, but in the actual > implementation in the FPGA it looks like the FIFO is full of zeros > after reset. After all zeros are read out of the fifo normal behaviour > starts again. > > I hope someone can help me with this. > > Thanks > Sebastian
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