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
On 4=D4=C28=C8=D5, =C9=CF=CE=E712=CA=B109=B7=D6, "MH" <b...@blahblah.blah> = wrote: > "wicky" <wicky.zh...@gmail.com> wrote in messagenews:1175935739.219549.22= 2410@q75g2000hsh.googlegroups.com... > > > Btw: what about Virtex-5 VSK (Video Starter Kit), I hear that it will > > support PCI-e. > > If you are looking for a Virtex-5 video development card with PCI express, > try this:http://www.imageproc.com/xilinx.php > > MH. Many thanks. Best Regards, WickyArticle: 117726
On Apr 5, 6:27 pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > We're hitting some slightly different bands, but the general concept is the > same. We're not trying to sample different bands simultaneously though. > > IIRC, our HW folks chose the Linear LTC2227. It is nicely low in power draw, > is single 3V supply, and it handles undersampling pretty well. For instance, > we're driving it with a 25.6 MHz clock rate with a 380 MHz IF (5 MHz BW > signal in something like the 11th aliasing band). > > The bits go into a TI "Graychip" GC5016 (I figure that's who you're > referring to when you said Grayscale). We use a small Altera Cyclone II to > package this data for sending to a AD Blackfin DSP (BF537?). The Blackfin > can run Linux (uCLinux), which is pretty impressive for a cheap low power > chip. > > Like one of the other responders said, you could pick your clocking rate > and/or mixer frequencies (if any) so that two (or more) of your bands fall > into different parts of your (folded) spectral response. The narrower each > of your bands are and the higher the clock rate the easier this gets to > plan. Then your DDC can pick each channel off regardless of band. Remember > that depending on the folding and mixing your frequencies might be > "reversed." You usually can tell the DDC to conjugate the output to get the > net result straight. > > HTH, > > Marty > > "morpheus" <saurs...@gmail.com> wrote in message > > news:1175702771.897449.271210@w1g2000hsg.googlegroups.com... > > > Hi Folks, > > I've been active on this forum asking questions on digital receiver. > > Earlier I was doing most of the work in the FPGA (thats how I > > architected it). Due to space constraints, this radio is going to be > > used as a Search and Rescue radio for the coast guard, I am re- > > architecting and planning to use a multi-channel digital receiver > > chip instead. This helps us to get rid of most of our analog front end > > and do minimal processing in the FPGA, and thus use a smaller FPGA > > also. > > The chips that come to mind are AD6654 and AD6624A. The AD6654A is > > special as it has the in-built ADC. > > Now some specs on my design requirements > > a) 4 channels, > > b) 121.5MHz - 245MHz band of interest. > > c) AM, FM, FSK demodulation. > > I have also looked at some Grayscale chips. I was wondering if you > > have any more suggestions. > > Thanks > > Morpheus Comprendi!!. I think these are really valuable solutions. I do agree, after some consideration, that with a little bit of modeling upfront, we can reduce the number of ADCs from 4 to 2 and then do the selection in the FPGA through DDS/filters. When you say, "that depending on the folding and mixing your frequencies might be "reversed." You usually can tell the DDC to conjugate the output to get the net result straight", do you mean, genearate negative sine, cosine (if using a Xilinx DDS core) to get the frequencies straight?Article: 117727
Hello Sir, Sorry for late reply, I couldn't check the group last week. Now I'm able to simulate the memory block in virtex also. I updated the xilinxcorelib libraries to updated ones, for which, the link was given in a readme.txt for project at http://www.xilinx.com/support/software/coregen/71i_coregen_examples.htm Thanks for your kind response. Regards, Veeresh On Mar 27, 9:55 am, "veeresh" <veeresh8...@yahoo.co.in> wrote: > Hello Sir, > > I'm trying to simulate a design involving Block RAM implemented > using core generator. > Please consider the example "Dual Port Block RAM v6.1" at > http://www.xilinx.com/support/software/coregen/71i_coregen_examples.htm > > I generated an empty test bench for this design. I'm able to do PAR > Simulation on virtex 2. When I tried same on virtex 4, Modelsim XE > simulator is giving error message saying two generics"en_ecc_read", > and "en_ecc_write" are not defined. > > My tool set is: > Tool : ISE 7.1 > Simulator : Modelsim XE III/Starter 6.0a > > Can you please help me to find the reason? > > Thanks and Regards,VeereshArticle: 117728
I do not have yet use this design but in my opinion, you have to connect an external clock to the SMA connector for clock input (this design is for memory testing) ; or change in the .ucf file NET CLK = ... to use onboard 50MHz crystal On 3 avr, 05:59, Dave <d...@comteck.com> wrote: > On Mon, 02 Apr 2007 10:54:30 +0200, Benjamin Todd wrote: > > Interesting that... > >http://download.micron.com/pdf/datasheets/dram/ddr/512MBDDRx4x8x16.pdf > > > If you read the differences between these memories, you see that the -5B is > > DDR400... whereas the -6 is DDR333... > > > Do you know whether the clock rate is 200M or 133-167M for the starter kit? > > The Readme says 133 MHz. > > > Actually, which starter kit are you using? I have a pile of kits, want to > > make sure I can't have the same problem... > > Spartan-3E Starter Kit (HW-SPAR3E-SK-US) > <http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.j...> > > ~Dave~Article: 117729
Adam You have not missed anything. The inner pins are for an enhancement of the DIL headers where we have inner strips with power pickup allowing easier use of multiple modules in a single header. If you plug in the module at the top of the header the the top left and right of the header are 0V and 3.3V respectively. You can see an example of the improved header already on our Broaddown4 product http://www.enterpoint.co.uk/moelbryn/broaddown4.html where we also go further and 2.5V and 1.8V are also available to modules on the LHS DIL Header on this product. We are going add the simple version of this as an enhancement to Raggedstone1 in the next few months when we do a minor revision of the product. I will be asking this group for opinions in the coming few weeks for what else we could improve on this product when we do this given we are trying to meet a low cost target with the product. We will also be looking at concepts for Raggedstone2 and possibly Raggedstone3 when we do this review. These products will not replace the Raggedstone1 but will have slightly different targets but again with the low cost, value for money, theme. John Adair Enterpoint Ltd. On 8 Apr, 21:25, Adam Megacz <meg...@cs.berkeley.edu> wrote: > By a stroke of luck, I figured it out. In order to program the board, > you must add this line to devlist.txt: > > f5045093 8 PROM > > Previously I had been using a value of "6" (like the other entries in > the file). Using "6" gives the behavior I explained before. Using > "8" results in correct programming. > > John, I suggest you add this to the raggedstone FAQ. > > One more question: I ordered the Ethernet PHY, but the pins on the > bottom of the PHY daughterboard don't match any of the headers on the > raggedstone. The daughtercard has two single-pin rows, plus four > additional pins that are offset diagonally from the top and bottom pin > of each row. The Raggedstone has only single-pin rows, none of which > appear to have a pin-hole in the diagonal position. > > Am I missing something? > > Thanks. > > - a > > > > > > "John Adair" <g...@enterpoint.co.uk> writes: > > Adam > > > Getting the chain of JTAG devices means there is a hardware level > > issue and manually override won't do a lot to help. > > > There are a few possibilities listed on the FAQ page here > >http://www.enterpoint.co.uk/moelbryn/raggedstone1_faq.html. Beyond > > that we occasionally see issues with noise on PC's. Using a different > > host to program and holding PC in reset is often enough to clear this > > issue. Long extension cables can also cause issues. If you still have > > an issue after that it might just be the programming cable is faulty > > and you should send an email to our board sales email and they will > > send out a replacement. You are not likely to get a response from them > > until Thursday as the sales and shipping team are shut down until then > > for Easter holidays. > > > John Adair > > Enterpoint Ltd. > > > On 7 Apr, 21:14, Adam Megacz <meg...@cs.berkeley.edu> wrote: > >> Hello, all... > > >> Has anybody gotten xc3sprog to work with the raggedstone board and its > >> included parallel programming cable? > > >> I had to add an entry to devlist.txt for the configuration PROM > >> (xc3sprog gets upset if it sees any unrecognized devices on the chain, > >> even if they're not the one being programmed). After doing that, I'm > >> able to program the S3 directly like this: > > >> ./xc3sprog pci_7seg.bit 1 > > >> The board's 7-segment LEDs go blank for a while and then come back on. > >> Here's the kicker: the board is currently running the "default" > >> bitstream that the board ships with, which counts down in hexadecimal. > >> After the LEDs go dark, they come back *at the same counter position > >> they were at before programming* and continue counting down. > > >> So, apparently the device is not only not getting programmed, but it > >> isn't even getting reset. Yet the LEDs go dark and xc3sprog reports > >> no errors. > > >> Weird. > > >> Any advice? > > >> - a > > >> -- > >> PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 > > -- > PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380- Hide quoted text - > > - Show quoted text -Article: 117730
Not sure if there's an efficient way to fix it... but in my experience, this happens when you generate your core into a directory other than your root project. I used to try to have /ISEProject/Source/Coregen in my directory structure, but ISE always tried to regenerate stuff for me. The problem is solved by regenerating the core into the root directory ISEProject/ but its a royal pain if you've got a lot of files you're trying to keep straight... if there's a better solution out there I'd love to hear about it as well! On Apr 8, 5:53 am, Sean Durkin <news_ap...@durkin.de> wrote: > Telenochek wrote: > > Nevermind, problem solved. > > How about sharing your solution with the group? ;) > > -- > My email address is only valid until the end of the month. > Try figuring out what the address is going to be after that...Article: 117731
Paul wrote: > Not sure if there's an efficient way to fix it... but in my > experience, this happens when you > generate your core into a directory other than your root project. I > used to try to have > /ISEProject/Source/Coregen in my directory structure, but ISE always > tried to regenerate > stuff for me. The problem is solved by regenerating the core into the > root directory ISEProject/ > but its a royal pain if you've got a lot of files you're trying to > keep straight... if there's a better solution > out there I'd love to hear about it as well! It may be as simple as having your core files in a common directory and setting your "Macro Search Path" in... I think it's the Translate properties in the GUI. I didn't offer this suggestion straight out because I didn't see how regenerating the core would change the fact that the core isn't in a searchable location.Article: 117732
Hi,
I'm trying to design a floppy disc 'raw reader' (to archive discs that have
been written in unusual formats that PCs can't read). I've got a basically
working data separator design that turns the MFM (or FM) data signal into a
data output and a data window signal. This is how it looks on a logic analyser
(note that the vertical : lines denote the bit cell boundaries):
__________ __________
DWIN __________| |__________| |__________
: : _ : _ _ :
DATA __________________________| |_____| |_| |_____________
: : : :
clock-0 clock-1 clock-1 clock-0
(noisy)
Basically, a transition (either H-L or L-H) on the DWIN (Data Window) line
denotes the start of a bit cell. If DATA is pulsed at least once within that
bit cell, then a 1 should be clocked into a shift register (a 16-bit SR used
to detect the synchronisation word). If there wasn't a pulse, then a zero
should be clocked into the shift register.
Now the problem I have is that in Verilog (or at least Xilinx ISE8.1 Verilog)
you can't trigger on both a positive and negative edge of a signal - the
language allows it, but ISE complains that it can't find a matching 'FF or
latch template' (error code Xst:899).
The idea I came up with was to have a D-type flip-flop wired with D=1, Q to
the SR's data line, and CLK wired to a signal that pulses every time there's a
DWIN edge. The problem I have is that I'm quite new to CPLDs, so I'm not sure
how to go about creating the 'pulse every transition' signal.
Am I thinking along the right lines here, or is there an easier (or just
another) way to do this?
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
usenet07@philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
If mail bounces, replace "07" with the last two digits of the current year.
Article: 117733Hi, I am trying to measure an input signal that will be a square wave of a certain unknown frequency in the range 1MHz to 4 MHz using an FPGA. I have no control over that input signal. The FPGA should be able to track the signal as it changes. Usually there is a +-5% max shift in frequency from time to time. There is no reference clock for this signal. I am not sure a simple counter will be an effective solution in this case. I am afraid of setup time issues since the internal FPGA clock will not be synchronized with the external signal. Can one phase lock two signals easily in an FPGA? I would probably need a counter running at 400 MHz to effectively to measure a 1% change in a 4MHz signal accurately. I am wondering if there is an asynchronous solution to this issue that might be more effective. Any ideas would be highly appreciated. Thanks a lot, AmishArticle: 117734
The "other way" is to use a clock that's much higher in speed (4x is very
safe). Sample the clock and data values. If the values match for 2
consecutive cycles, the values are valid and usable otherwise they might be
in the middle of changing and should be ignored until 2 cycles are
consistent. If the dual-edge transition you're looking for has transitioned
either way within that sampled data, you have your data.
By using a master clock and sampling the data *and* floppy clock with that
master clock, you can divorce the algorithm needs (dual edge) from the
hardware (single edge). One system clock is significantly easier to deal
with than multiple clocks in one FPGA. If you can't come up with a single
clock FPGA design because of the design requirements, fewer clocks are
almost always better.
"Philip Pemberton" <usenet07@philpem.me.uk> wrote in message
news:fr6dnV9DXtof1ofbRVnyhwA@pipex.net...
> Hi,
> I'm trying to design a floppy disc 'raw reader' (to archive discs that
> have been written in unusual formats that PCs can't read). I've got a
> basically working data separator design that turns the MFM (or FM) data
> signal into a data output and a data window signal. This is how it looks
> on a logic analyser (note that the vertical : lines denote the bit cell
> boundaries):
>
> __________ __________
> DWIN __________| |__________| |__________
> : : _ : _ _ :
> DATA __________________________| |_____| |_| |_____________
> : : : :
>
> clock-0 clock-1 clock-1 clock-0
> (noisy)
>
> Basically, a transition (either H-L or L-H) on the DWIN (Data Window) line
> denotes the start of a bit cell. If DATA is pulsed at least once within
> that bit cell, then a 1 should be clocked into a shift register (a 16-bit
> SR used to detect the synchronisation word). If there wasn't a pulse, then
> a zero should be clocked into the shift register.
>
> Now the problem I have is that in Verilog (or at least Xilinx ISE8.1
> Verilog) you can't trigger on both a positive and negative edge of a
> signal - the language allows it, but ISE complains that it can't find a
> matching 'FF or latch template' (error code Xst:899).
>
> The idea I came up with was to have a D-type flip-flop wired with D=1, Q
> to the SR's data line, and CLK wired to a signal that pulses every time
> there's a DWIN edge. The problem I have is that I'm quite new to CPLDs, so
> I'm not sure how to go about creating the 'pulse every transition' signal.
>
> Am I thinking along the right lines here, or is there an easier (or just
> another) way to do this?
>
> Thanks.
> --
> Phil. | (\_/) This is Bunny. Copy and paste
> Bunny
> usenet07@philpem.me.uk | (='.'=) into your signature to help him
> gain
> http://www.philpem.me.uk/ | (")_(") world domination.
> If mail bounces, replace "07" with the last two digits of the current
> year.
Article: 117735"axr0284" <axr0284@yahoo.com> wrote in message news:1176129527.026627.123590@n59g2000hsh.googlegroups.com... > Hi, > I am trying to measure an input signal that will be a square wave of > a certain unknown frequency in the range 1MHz to 4 MHz using an FPGA. > I have no control over that input signal. The FPGA should be able to > track the signal as it changes. Usually there is a +-5% max shift in > frequency from time to time. There is no reference clock for this > signal. > > I am not sure a simple counter will be an effective solution in this > case. I am afraid of setup time issues since the internal FPGA clock > will not be synchronized with the external signal. Can one phase lock > two signals easily in an FPGA? I would probably need a counter > running at 400 MHz to effectively to measure a 1% change in a 4MHz > signal accurately. > > I am wondering if there is an asynchronous solution to this issue that > might be more effective. Any ideas would be highly appreciated. Thanks > a lot, > Amish You can measure with a simple counter if you look at the average over several pulses rather than just one period. If you used asynchronous solutions to try to phase lock, that phase lock takes many cycles to become stable and reduce the error. I have used a simple counter and run the count value through a simple low pass filter to have displayed results to high accuracy. An average can be taken over n pulses by accumulating a count over those n pulses, not individually. The only caveat to using simple counts is that the first and last edges can both be slightly off if the clocks are lining up. The count error will be barely more than +/-1 from ideal for the worst case whether you're sampling 1 or 100 pulses. To get around the asynchronous sampling problem, just use a syncronizer for your input frequency to sample it into your counter time domain. If you detect in the counter's clock domain when the input frequency transitions, the clock sample will have the standard setup/hold time for the counter clock's domain. It's the single synchronizer that can violate the setup/hold time with little concern. So use a clock frequency you're comfortable with (40 MHz? 100 MHz?) and use a counter to measure several pulses. If you need extreme accuracy *per pulse* then your task is beyond simple FPGA design though the task is achievable. Don't overstep your requirements if a simple design will suffice.Article: 117736
Evnin' As Linux versions after 2.6.13 don't have devfs anymore... will there be soon a new version of the byteblaster.tar.gz parallel driver or has someone a patch for it? cheers rickArticle: 117737
Philip Pemberton schrieb: > Now the problem I have is that in Verilog (or at least Xilinx ISE8.1 > Verilog) you can't trigger on both a positive and negative edge of a > signal - the language allows it, but ISE complains that it can't find a > matching 'FF or latch template' (error code Xst:899). If you really need both clock edges, think about a pseudo-dual-edge flipflop: <http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf> RalfArticle: 117738
I am looking for a FPGA board which supports some features: 1- PCI interface 2- 1G ethernet port 3- Linux driver support 4- Less than 1,000 USD Would any one please show me the suitabe cards or give some suggestions. Thanks ThuyArticle: 117739
Philip Pemberton wrote: > > Now the problem I have is that in Verilog (or at least Xilinx ISE8.1 > Verilog) you can't trigger on both a positive and negative edge of a > signal - the language allows it, but ISE complains that it can't find a > matching 'FF or latch template' (error code Xst:899). > > The idea I came up with was to have a D-type flip-flop wired with D=1, Q > to the SR's data line, and CLK wired to a signal that pulses every time > there's a DWIN edge. The problem I have is that I'm quite new to CPLDs, > so I'm not sure how to go about creating the 'pulse every transition' > signal. > > Am I thinking along the right lines here, or is there an easier (or just > another) way to do this? > > Thanks. The FFs in most (all?) FPGAs/CPLDs can only operate on one edge. If you want to use both edges, you have to use two distinct sets - one for each edge polarity. Since floppies are low-speed devices, an oversampling edge detection scheme would do the job: you sample your input 3-4X faster than your shortest event (pulse) and XOR the samples with the delayed previous sample to detect edges. This XOR's output can be used as the clock enable for the remaining logic. Unless you really know what you are doing, you should not use combinational or non-clock/glitchy signals to drive clocks.Article: 117740
I am currently trying to free-up some DCMs for use in other parts of our design, so I am trying to make some MGTs share DCM outputs. Currently I have one DCM per each of the eight MGTs which uses all of our DCMs. For reference, we are on a Virtex II-pro trying to communicate at a rate of 2.5Gbs in two-byte mode. Xilinx document UG024 talks about a case where no DCMs are needed at all, but it isn't clear on when this solution is suitable (pg. 46). I thoguht we may at least be able to use one DCM for the top four MGTs and another for the bottom four. Any thoughts or experiences related to this issue or clocking MGTs on a Virtex II in general would be appreciated. ---Matthew HicksArticle: 117741
Any Cypress FX2 (USB) gurus out there? I have one of these devices on an FPGA board (Digilent Nexys), which only provides an 8-bit external datapath instead of 16 bits. I'd like to stream substantially wider words (32, maybe 48 bit) to a PC application. Could anyone provide some clarity on what mechansims exist to synchronize the byte-wide data to application word boundries? Is there something I can do to insure that each USB packet begins on a word boundary? The boundry locations are readily available to the FPGA code, the question is how to communicate that information to the USB engine - is there a way to force creation of a new packet? Obviously in-band signalling for data framing remains an option, but I would very much like to avoid resorting to that. Thanks for any ideas - I haven't given up on figuring this out from the data sheets & manuals, but given their length it's not going quickly.Article: 117742
Kunal, Since this is for a DAQ application, see if you can utilize the boards available at EDT.(www.edt.com) Seems like it should be a perfect choice. Vivek On Apr 7, 4:08 am, n...@puntnl.niks (Nico Coesel) wrote: > n...@puntnl.niks (Nico Coesel) wrote: > >"Kunal" <kunals.spam.acco...@gmail.com> wrote: > > >>> PCIE is killing of PCI66 very rapidly > > >>This is a good point. > > >>> Is this an academic application? If so some vendors like ourselves > >>> have University discount schemes. > > >>This is for university research, and we're basically looking for the > >>easiest and cheapest way to get about 600-800 Mbits of data onto a PC > >>without resorting to National Instruments cards (including their FPGA > >>product). > > >>We're certainly not closed to the idea of using PCIe, although it > >>would require purchasing new computers. > > >>It seems that most FPGA PCI boards are tailored to embedded > >>applications; since our application is a relatively simple one (where > >>the complexity is in transferring the data from FPGA to PC), this > >>seems a bit overkill. > > >>Nevertheless, we're still exploring our options (in fact, a Spartan > >>chip could work, but we'd need the higher-end sizes, since we need to > >>process roughly 512 channels of data; this would require quite a bit > >>of the FPGA's resources). > > >A design consisting of multiple Spartan FPGAs is far cheaper than one > >big Virtex. Still, 100MB/s is not something that is easely transferred > >through the old style PCI33 or PCI66 bus. You'll find other devices > >also demand bandwidth and you'll want bus-mastering as well. > > >An easier way to design such a beast is moving to PCI Express PCs and > >use a PLX PCI express to PCI33 bridge chip. Now you have a dedicated > >PCI33 bus you can use without having to concern yourself with other > >devices which reside on the same bus. Perhaps you can even get by > >using a less strictly timed PCI implementation since you also have > >full control over all signal integrity issues. > > >The driver is another problem. If you can find a device which does > >almost what you want, you can try to mimic it and use drivers that > >come with Windows. Back when I had to do my first PCI design, I simply > >emulated a 16550 style UART to exchange data at a low rate. Windows > >knew how to talk to it so I could move on without having to wait for > >the software people to come up with a driver. > > I just got another idea on the mimic thing: If you let your fpga > design mimic a network card (an NE2000 or Realtek as long as the > drivers can deal with bus mastering), you can put your data into UDP > packets (maybe one port per stream??). All you need to do in your > application software is listen to the proper network socket. No need > to write a driver. With some care, your software and hardware will run > on any platform instantly. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U opwww.adresboekje.nlArticle: 117743
> > I know all this is possible because Chipscope itself is such an application. > However, as far as I know, ChipScope does not let the user write into the > chip to control a design. > Have you tried looking at ChipScope's VIO (Virtual Input/Output Core)? It might be exactly what you need.Article: 117744
When simulating a post-routed design in ModelSim, I get a number of setup, hold, recovery violations such as: # ** Warning: /X_FF SETUP Low VIOLATION ON CE WITH RESPECT TO CLK; Can somebody explain what does "Low VIOLATION" mean? and what's the difference between this and "High VIOLATION"? Is this with respect to signal levels? or is it an indication of the degree of violation? Thank you.Article: 117745
We've used the FX2 on multiple projects with FPGAs. The FX2 delivers a stream of data bytes to the host, from the hosts perspective, it hasn't a clue if the external FX2 bus is 8 or 16 bits. As long as the transfer lengths are an even number of bytes and your FPGA code properly converts your internal 16/32/48 bit data into a byte stream, you should have no problems. Yes, you can also force the start of a new packet using the PKTEND pin, but your USB bandwidth may suffer since you will be sending short packets. John Providenza On Apr 9, 10:02 am, cs_post...@hotmail.com wrote: > Any Cypress FX2 (USB) gurus out there? > > I have one of these devices on an FPGA board (Digilent Nexys), which > only provides an 8-bit external datapath instead of 16 bits. I'd like > to stream substantially wider words (32, maybe 48 bit) to a PC > application. > > Could anyone provide some clarity on what mechansims exist to > synchronize the byte-wide data to application word boundries? Is > there something I can do to insure that each USB packet begins on a > word boundary? > > The boundry locations are readily available to the FPGA code, the > question is how to communicate that information to the USB engine - is > there a way to force creation of a new packet? > > Obviously in-band signalling for data framing remains an option, but I > would very much like to avoid resorting to that. > > Thanks for any ideas - I haven't given up on figuring this out from > the data sheets & manuals, but given their length it's not going > quickly.Article: 117746
John_H wrote:
> By using a master clock and sampling the data *and* floppy clock with that
> master clock, you can divorce the algorithm needs (dual edge) from the
> hardware (single edge). One system clock is significantly easier to deal
> with than multiple clocks in one FPGA. If you can't come up with a single
> clock FPGA design because of the design requirements, fewer clocks are
> almost always better.
Thanks for the suggestion, John (and Daniel and Ralf). I've already got an
8MHz master clock that's used to drive the data separator, and seeing as the
maximum data rate is only 1Mbit/sec, I've used the 8MHz clock to drive an
oversampling transition detector to pick up the data window transitions, and
then used a shift register to pick up the sync word:
---------- start code
module syncdetect(clock, data, dwin, reset, sync);
input clock; // sampling clock, min 4*f_DWIN
input data; // data input
input dwin; // data window
input reset; // reset input
output reg sync; // sync-detect output
//////////
// DWIN transition detector
reg [1:0] detector;
wire dwin_transition; // 1 = transition detected on DWIN
always @(posedge clock or posedge reset) begin
if (reset) begin
detector <= 2'b00;
end else begin
detector <= {detector[0], dwin};
end
end
assign dwin_transition = (detector == 2'b01) | (detector == 2'b10);
//////////
// data shift register
reg [15:0] shiftreg;
reg dar;
always @(posedge dwin_transition or posedge data or posedge reset) begin
if (reset) begin
// reset -- clear the SR, DAR and SYNC
sync <= 1'b0;
dar <= 1'b0;
shiftreg <= 16'h0000;
end else if (dwin_transition) begin
// DWIN transition: clock bit into SR...
shiftreg <= {shiftreg[14:0], dar};
// ... and clear the data register
dar <= 0;
// if sync word found, set SYNC
if (shiftreg == 16'h4489) begin
sync <= 1'b1;
end
end else begin
// no transition, DATA must be high, so set DAR
dar <= 1;
end
end
endmodule
------- end code
This does what I need it to do (according to the ISE simulator), but a few of
ISE's warnings are worrying me:
WARNING:Xst:1467 - "syncdetect.v" line 53: Reset or set value is not constant
in <sync>. It could involve simulation mismatches
WARNING:Xst:1467 - "syncdetect.v" line 55: Reset or set value is not constant
in <shiftreg>. It could involve simulation mismatches
WARNING:Xst:737 - Found 1-bit latch for signal <sync>.
WARNING:Xst:737 - Found 16-bit latch for signal <shiftreg>.
<syncdetect>.
The lines in question are:
52 // reset -- clear the SR, DAR and SYNC
53 sync <= 1'b0;
54 dar <= 1'b0;
55 shiftreg <= 16'h0000;
56 end else if (dwin_transition) begin
Xilinx's support site is no help, so what is ISE complaining about, and how
can I get rid of the warning?
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
usenet07@philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
If mail bounces, replace "07" with the last two digits of the current year.
Article: 117747On Apr 9, 12:54 pm, "johnp" <johnp3+nos...@probo.com> wrote: > We've used the FX2 on multiple projects with FPGAs. > > The FX2 delivers a stream of data bytes to the host, from the > hosts perspective, it hasn't a clue if the external FX2 bus is > 8 or 16 bits. As long as the transfer lengths are an even > number of bytes and your FPGA code properly converts your > internal 16/32/48 bit data into a byte stream, you should > have no problems. In general I'd agree - but my fear is that if synchronization was lost for any reason, there'd be no way to get it back. And maybe not even any way to know, other than the data not making any sense. > Yes, you can also force the start of a new packet using the PKTEND > pin, but your USB bandwidth may suffer since you will be sending short > packets. Thanks - that's more what I was looking for. I wouldn't do it every word, but more like every packet or several packets. I wonder if there is any problem with asserting this at every point where the packet would automatically end anyway... will have to get it set up and see.Article: 117748
Philip,
See what happens with the second allways block specified as
always @(posedge clock or negedge reset)
The way you have it currently set with
always @(posedge dwin_transition or posedge data or posedge reset)
is confusing at best. When you detect a transition at the 8 MHz clock you
want to execute the non-reset code. The always has the clock and the code
has the transition conditional.
The last else isn't quite right. If there's no transition of dwin, you want
to accumulate dar - dar<=dar|data; - and if there is a transition, you use
dar and reset it, perhaps dar<=0, perhaps dar<=data depending on how the
timing lines up.
That might get you closer to your destination but I haven't thoroughly
evaluated the code.
- John_H
"Philip Pemberton" <usenet07@philpem.me.uk> wrote in message
news:Tb2dnZSwYN4A4ofbnZ2dnUVZ8tWnnZ2d@pipex.net...
> John_H wrote:
>> By using a master clock and sampling the data *and* floppy clock with
>> that master clock, you can divorce the algorithm needs (dual edge) from
>> the hardware (single edge). One system clock is significantly easier to
>> deal with than multiple clocks in one FPGA. If you can't come up with a
>> single clock FPGA design because of the design requirements, fewer clocks
>> are almost always better.
>
> Thanks for the suggestion, John (and Daniel and Ralf). I've already got an
> 8MHz master clock that's used to drive the data separator, and seeing as
> the maximum data rate is only 1Mbit/sec, I've used the 8MHz clock to drive
> an oversampling transition detector to pick up the data window
> transitions, and then used a shift register to pick up the sync word:
>
> ---------- start code
>
> module syncdetect(clock, data, dwin, reset, sync);
> input clock; // sampling clock, min 4*f_DWIN
> input data; // data input
> input dwin; // data window
> input reset; // reset input
> output reg sync; // sync-detect output
>
> ////////// // DWIN transition detector
>
> reg [1:0] detector;
> wire dwin_transition; // 1 = transition detected on DWIN
>
> always @(posedge clock or posedge reset) begin
> if (reset) begin
> detector <= 2'b00;
> end else begin
> detector <= {detector[0], dwin};
> end
> end
>
> assign dwin_transition = (detector == 2'b01) | (detector == 2'b10);
>
> //////////
> // data shift register
> reg [15:0] shiftreg;
>
> reg dar;
>
> always @(posedge dwin_transition or posedge data or posedge reset) begin
> if (reset) begin
> // reset -- clear the SR, DAR and SYNC
> sync <= 1'b0;
> dar <= 1'b0;
> shiftreg <= 16'h0000;
> end else if (dwin_transition) begin
> // DWIN transition: clock bit into SR...
> shiftreg <= {shiftreg[14:0], dar};
> // ... and clear the data register
> dar <= 0;
>
> // if sync word found, set SYNC
> if (shiftreg == 16'h4489) begin
> sync <= 1'b1;
> end
> end else begin
> // no transition, DATA must be high, so set DAR
> dar <= 1;
> end
> end
>
> endmodule
>
>
> ------- end code
>
> This does what I need it to do (according to the ISE simulator), but a few
> of ISE's warnings are worrying me:
>
> WARNING:Xst:1467 - "syncdetect.v" line 53: Reset or set value is not
> constant in <sync>. It could involve simulation mismatches
> WARNING:Xst:1467 - "syncdetect.v" line 55: Reset or set value is not
> constant in <shiftreg>. It could involve simulation mismatches
> WARNING:Xst:737 - Found 1-bit latch for signal <sync>.
> WARNING:Xst:737 - Found 16-bit latch for signal <shiftreg>.
> <syncdetect>.
>
> The lines in question are:
> 52 // reset -- clear the SR, DAR and SYNC
> 53 sync <= 1'b0;
> 54 dar <= 1'b0;
> 55 shiftreg <= 16'h0000;
> 56 end else if (dwin_transition) begin
>
> Xilinx's support site is no help, so what is ISE complaining about, and
> how can I get rid of the warning?
>
> Thanks.
> --
> Phil. | (\_/) This is Bunny. Copy and paste
> Bunny
> usenet07@philpem.me.uk | (='.'=) into your signature to help him
> gain
> http://www.philpem.me.uk/ | (")_(") world domination.
> If mail bounces, replace "07" with the last two digits of the current
> year.
Article: 117749Linux driver to support what? The FPGA card is generic logic ready to do your bidding as you design it. Drivers are to apply fuctionality between software and target hardware. But your target hardware is a blank slate. The ethernet port needs a mac and TCP/IP stack added on before you can use it, doesn't it? "Thuy Pham" <thuyp@xilinx.com> wrote in message news:461A5E46.B329EA3B@xilinx.com... >I am looking for a FPGA board which supports some features: > > 1- PCI interface > 2- 1G ethernet port > 3- Linux driver support > 4- Less than 1,000 USD > > Would any one please show me the suitabe cards or give some > suggestions. > > Thanks > Thuy >
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