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
John Larkin wrote: > On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote: > > > > >John Larkin wrote: > >> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote: > >> > >> > >> >So the Fpga to Fpga routing worked - good. > >> > >> That's not what we did. We designed a clock deglitcher to go inside > >> the FPGA. > > > >Enough propagation delays to cover the dwell at the switching > >threshold, and a state machine to make sure that the clock only changes > >state once in that interval? > > > We did my original #2 suggestion, a tapped delay line driven from the > pin, driving an r-s flipflop. Set the flop if all the taps are 1s, > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. > The delay line is a string of eight buffers, about 10 ns overall. > > We'd have done Peter's circuit if we'd learned of it sooner. > > It's interesting that my post evoked two classes of response: > > 1. It can't be done, don't do it, kluge the boards (also the official > Xilinx response!) I think I'm in that catagory, though I'd describe my response as saying that it shouldn't be done in software - if for no other reason than that the dwell time at 1.2V eats into your timing error budget - and that the time you'd already spent on looking for a software solution should have been enough to find one (which turns out to have been correct). > 2. Yes, and here are my ideas on how you could do it/how I've already > done it/interesting asides. Granting that I was fixated on the hardware solution, I did suggest how you might hack the board, based on a problem that I'd been a party to, many years ago. -- Bill Sloman, NijmegenArticle: 99851
I'm looking for the software for the H.O.T. II Hardware Object Technology Development System by the VIrtual Computer Corporation. Their are two different versions, one that uses a Xilinx XC4062XLT and the other XCS40. I have both. I've been to the company website but there are a lot of broken links and the contact information has been removed. Thanks, DerekArticle: 99852
Thanks for your answer. The "Slice Packing" option in ISE's Synthesize-XST properties is already set by default but that only makes synthesis use the LUT#_L primitives. I couldn't find the LUT-Slice association in any file. In any case, I wish there was a way to generate the netlist of Slices using already existing tools. Is there a "SLICE" primitive somewhere, that could be used by synthesis tools? What I'm trying to do is generate a "uniform" synthesis output (uniform in the sense that only one module is almost exclusively used). I don't really care whether it is Xilinx's Slices or some other FPGA vendor's or whatever. Just a "uniform" netlist output from synthesis. Any suggestions? YannisArticle: 99853
Austin and Falk, thankyou again. I'm aware of the development costs. But there is the self-satisfaction, and $20 is more than the price of the FPGA itself. Less one chip to understand, less one chip in the BOM, less space on the PCB, less one device on the JTAG chain... And I have some time. I had another idea to diminish the jitter: Let's suppose CLKA is the 8.192MHz clock that I want to track. CLKB is a 8.192MHz clock generated by a stable oscilator. CLKB will drift from CLKA at stable rate "R" (in radians/second). So, using the DCM Phase Shifter at the "VARIABLE Phase Shift Mode", and incrementing/decrementing the phase shift value at the correct rate "R", it's possible to accomplish the holdover capability. As the Phase Shifter can have 512 steps (for the whole 2*pi radians), we can have a 1/8.192MHz/512=238ps jitter. Multiplying CLKB by N (and after the Phase Shifter, dividing it by N), the jitter will be divided by N. Can it be done? Luiz CarlosArticle: 99854
Dear, I have a problem with my block-ram, namely I have made new perheperal (opb-ipif) and I by means of coregen dpram have produced. But the problem is when I want simulate something in modelsim 6.0d then reaches I the decision that there are no DIN. The dates become by means of a c programme (works) to slv3 a register and there din <= slv3; . You has problem ever this come against? Thanks in advance, JanArticle: 99855
oen_no_spam@yahoo.com.br schrieb: > I had another idea to diminish the jitter: > Let's suppose CLKA is the 8.192MHz clock that I want to track. > CLKB is a 8.192MHz clock generated by a stable oscilator. > CLKB will drift from CLKA at stable rate "R" (in radians/second). > So, using the DCM Phase Shifter at the "VARIABLE Phase Shift Mode", and > incrementing/decrementing the phase shift value at the correct rate > "R", it's possible to accomplish the holdover capability. > As the Phase Shifter can have 512 steps (for the whole 2*pi radians), > we can have a 1/8.192MHz/512=238ps jitter. > Multiplying CLKB by N (and after the Phase Shifter, dividing it by N), > the jitter will be divided by N. I doubt that you can savely multiply the 8.192 MHz clock using a DCM. The DCM is quite sensitive to incomming jitter. Its "only" designed to do multiplication/phase shift/whatever using almost crystal clear clocks comming from a XO or similar source. I think using a RC-oscillator as a clock source will make the DCM lose track. Similar thing for the integrated PLLs from vendor A. ;-) But Iam a little bit confused. Should a PLL not have MUCH better jitter tolerance? I would use a high quality (TC)XO, multiply this using a DCM and generate my 8.912 clock. If really necessary, use a LC-tank/analog PLL/whatever to clean up residual jitter. Regards Falk P.S. I remember Ray asking for some properties of the phase shifter to do some similar tricks (fast setting of phase shift). AFAIK the answers from Xilins were rather disillusioning.Article: 99856
Hi Prav, Not sure which University you work for but I would advice you to talk to your supervisor and get your EDA tools and target technology sorted out. You can also follows Mike's advice and try to get hold of an evaluation license for Spectrum/Synplify/Precision although I suspect this will fail for Mentor since they have a special University program (Europractice here in the UK). You can also try to contact Actel directly to see if they can lend you a ProASIC board and a temp license for Libero, no harm in trying..... Hans www.ht-lab.com <praviendre@hotmail.com> wrote in message news:1143643376.190947.68570@v46g2000cwv.googlegroups.com... > What should i do mate :). my ..... uni still uses ancient software and > they are bloody hard to use. Even the operating system is Solaris. and > i bloody hate it. > > Today i got rid of some of the components in the top design (obviously > circuit doesn't work properly) and it gave me the edn file after like > 30 mins. The full design still running and now its like 25 hours > !!!!!!!! > > I thought about to move to Altera or Xilinx but university doesn't > have the fabrication facilities for them. So i may have to stick to > actel 1280XL. > > thanks anyway > prav >Article: 99857
Also look at the Virtex II (not pro) User's guide. Chapter 5 shows good layout practices and routability guidelines. Among other things note that the via pattern for the fully populated grid parts creates a "+" shaped opening that can be used to place your bypass caps. Aurelian Lazarut wrote: > A good development board (Avnet, Insight, Xilinx) to look at, can give > you some ideas. > Aurash > > maxascent wrote: > > Hi > > > > I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone > > have any tips for the placement of the bypass caps. I want to use 0603 caps > > and normal PTH vias. I can see that it might get a bit crowded trying to > > position a lot of caps under the device near to the power pins with all > > those vias. > > > > Cheers > > > > JonArticle: 99858
Falk Brunner schrieb: >> Multiplying CLKB by N (and after the Phase Shifter, dividing it by N), >> the jitter will be divided by N. > > > I doubt that you can savely multiply the 8.192 MHz clock using a DCM. One even more basic problem. The minimum input frequency for the DCM is 24 MHz. Regards FalkArticle: 99859
Hi all, I would like to ask if anyone has implemented a physical usb interface in a development board of altera that has not mounted a usb inf. The core for usb1.1 and 2.0 are available but do i need certain physical layer to implement usb? I heared that for low speed i dont need to implement anythin just drive the wires into the fpga but for high speed i need to implement the phy intf. Any suggestions? ThanksArticle: 99860
In article <442b7087$0$58081$742ec2ed@news.sonic.net>,
Tommy Thorn <foobar@nowhere.void> wrote:
>JJ wrote:
>> I am surprised that we haven't seen alot more native FPGA MTA designs
>> though,.
>In addition to what I mentioned, there's surely more inertia issues and
>the complication of multi-threaded software (assuming you can even take
>advantage of it).
I've worked on FPGA based NPs. It is a no-brainer for this case, each
packet can be treated as a separate thread. With enough buffering it's
feasible to have 16 threads, which conveniently matches the size of Xilinx
SRL16s. A simple micro-engine will run at 200 MHz with this technique, and
ends up being the same physical size as the single-threaded version.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 99861Hi all, I need to get a feedback from you experts on some of the guidelines I adopted within my project with a Spartan3 FT256: 1) so far only 100 I/O pins out of 173 have been assigned, all the others will be sent to a common connector for future use. In order to handle, in future, all the pins available I decided to build up a PDS large enough for all the Vcc/GND couples. I followed the suggestions of xapp623 and here's what I calculated: Vcco: 14x 0.01uF, 6x 0.1uF, 4x 1uF, 1x 10uF; Vccint: 4x 0.01uF, 2x 0.1uF, 2x 1uF, 1x 10uF; Vccaux: 4x 0.01uF, 2x 0.1uF, 2x 1uF; 2) I'll have to deal with a Blackfin DSP which has very steep rising and falling edges, so I think I'll need termination resistances, or to use DCI, but as far as I'm working with the LVCMOS33 standard, there seem to be no DCI on input pins, what should I do? 3) I'd like to use the same pins of the DSP for both serial configuration and normal serial communication with the FPGA, to accomplish that the DSP_ATA_OUT will be connected to the DIN of the FPGA. This pin is dual-purpose so, after configuration, I'll use it as FPGA_DATA_IN. The CCLK, instead, is a dedicated pin, so I need to redirect, after configuration, the DSP_CLOCK signal from CCLK to the FPGA_SERIAL_CLOCK. What would you suggest me to do, to just connect DSP_CLOCK to both FPGA_SERIAL_CLOCK and CCLK at the same time (considering that during startup the former is Hi-Z, while during normal work the latter will be Hi-Z), or should I place some logic gates to close one path and to open the other, switching with the DONE signal? Thanks, MarcoArticle: 99862
John, Thanks. This does help a lot. I appreciate your post. I'm still slightly confused about this master and slave terminology. Myself and a couple others have been trying to understand it, but it's pretty convoluted. Is master always an output from microblaze and slave always an input to microblaze? Also, I'm a little confused as to why when I add an FSL to microblaze, I get a SFSL and a MFSL. This implies that the FSL is bidirectional when it's stated in the FSL datasheet that it's a unidirectional bus. Confusing. I wish they would've used terms other than master and slave. I'm assuming the port map you provided above is from the viewpoint of ublaze? The FLS0_S_READ and FLS0_S_CLK signals are outputs. My question is, outputs to where? I don't know why they'd go to the VHDL. They should go to the FSL, as they are the control signals that pop off the data into ublaze. I'm guessing you're in Austrailia? If that's true you're sleeping and I hope to here from you tomorrow. Regards, DaleArticle: 99863
Phil Tomson wrote: > What format is the truth table in? (BLIF, PLA, some other internal data > structure) Currently just a 2^n bit table, with a linked list for the associated var's. > So is this the tech mapping step? You've already created the truth table that > represents some part of the design and you need to map it into the underlying > architecture. Sounds interesting. Internally, each signal in TMCC/FpgaC has always been a truth table with var list, limited to 4 inputs, and mapped to LUTs at netlist output time. Simple optimizations, like don't cares and duplicate removal have been applied to this 4-lut set to generate a reasonable netlist, that's a little deeper than can be achieved by allowing the internal representation to be wider than a 4-LUT. Widening up the internal representation allows for F5/F6 MUX's to be easily used, controlling the depth of the LUT tree, and better don't care removal, at the cost of more effort to decompose the truth table at the technology mapping step. > Ah, yes, Alan is on the cutting edge with this And-Inverter Graph stuff. He's > also a very good programmer. > Can you make use of what is already in ABC? While I would hesitate to use > code from some other university projects that have appeared in the past, I > would not hesistate to use Alan's code; it's generally engineered very well. I've looked at a number of routing and mapping solutions over the last couple years with conflicting project goals for FpgaC. Both excellent static map/route and excellent fast dynamic compile load and go or Just-In-Time styles seem to be needed. Because of frequent larger word widths, there are some additional twists, like replication to minimize fan-out which become useful at some point. Where to start has always been an interesting problem. It seems that maybe just looking at the technology mapping in a general way for specific devices is a good start. The ideas in ABC, and related educational projects, are certainly a good grounding to start with.Article: 99864
Phil Tomson wrote: > Can you make use of what is already in ABC? I should probably note that I didn't want to make an implementation choice, allowing whoever wants this project to make that choice, which might include their own research work. This could easily be a one, two or more person project as it can quickly expand to meet broader needs ... or it could be a class project with a lasting legacy.Article: 99865
On 30 Mar 2006 02:32:08 -0800, bill.sloman@ieee.org wrote: >> It's interesting that my post evoked two classes of response: >> >> 1. It can't be done, don't do it, kluge the boards (also the official >> Xilinx response!) > >I think I'm in that catagory, though I'd describe my response as saying >that it shouldn't be done in software - if for no other reason than >that the dwell time at 1.2V eats into your timing error budget - It doesn't. We're running a 300 MHz FPGA at 16 MHz. Pushing the clock edges a few ns one way or the other doesn't matter. If you reject a concept out of hand, you're not likely to subsequently contribute interesting ideas on how to implement it. >and >that the time you'd already spent on looking for a software solution >should have been enough to find one (which turns out to have been >correct). It was. And if we'd waited a few hours, we'd have used Peter Alfke's circuit, which preserves clock edge timing and is quite a bit more elegant than our atrocity. Peter is the senior-stateman Xilinx app engineer (he wrote a lot of their appnotes) and he invented his deglitch thing on the spot for us. Our "official" Xilinx fae was a #1 type, "it shouldn't and can't be done." I met Peter at the now-departed Foothill Electronic Flea Market, where we both had our heads inside a big cardboard box of old books. After that intimacy, we naturally started talking, and he convinced me that we should dump Actel for Xilinx. He even told me where to get the student version of the software cheap! He had a great line: "I can tell by your hair that you'll prefer schematic entry." >> 2. Yes, and here are my ideas on how you could do it/how I've already >> done it/interesting asides. > >Granting that I was fixated on the hardware solution, I did suggest how >you might hack the board, based on a problem that I'd been a party to, >many years ago. The coax hack wouldn't work, for the exact reason we have trouble with the existing clock net: the xo can't put enough voltage into a 50 ohm line. Besides, the hack would be hideous. If anything is truly "unacceptable" around here, it's ugly boards. JohnArticle: 99866
maxascent wrote: > Hi > > I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone > have any tips for the placement of the bypass caps. I want to use 0603 caps > and normal PTH vias. I can see that it might get a bit crowded trying to > position a lot of caps under the device near to the power pins with all > those vias. The main principal behind decoupling caps is to minimize the area of the loop made by path from the power pin through the trace, cap and trace back to a ground pin. This area determines the inductance of the loop and limits the effectiveness of the capacitors. Anything that enlarges the loop area will create a problem with high speed decoupling. My recommendation is to use even smaller caps, 0402 is good, and to put them right at the Vcc pins on the other side of the board, of course. If you check the impedance curves for ceramic chip caps you will find that at the frequencies of interest, they are inductive. So the actuall value of capacitace is not so important. The smaller package normally has lower inductance and therefore has a lower impedance regardless of capacitance. I checked these graphs a few years ago when 0402 was not so common and found that a 0.01 uF 0603 cap had a lower impedance than an 0805 0.1 uF cap. So focus on lowering the impedance at the important frequencies, not necessarily on adding capacitance.Article: 99867
In article <442acdf6$1@usenet01.boi.hp.com>,
at) hp . com (no spaces)" <"J o h n _ E a t o n (at) hp . com (no spaces <"J o h n _ E a t o n (at) hp . com (no spaces)"> wrote:
>And here is what we use in our coding standard
>wire [31:0] a;
>wire [31:0] b;
>reg [32:0] result;
>reg [32:0] next_result;
>always@(*)
> begin
> next_result = a + b ;
> end
>always@(posedge clk)
> result[32:0] <= next_result[32:0];
I've often wanted a Verilog refactoring tool which would convert between
Mealy and Moore: this is because I usually like everything to be in a single
clocked always block (much less typing, easier to read, forces you to
pipeline), but sometimes you decide later that you really need that Mealy
output...
I'm know the rules and take advantage of bug-free synthesis tools. For
example:
always @(posedge clk)
begin
x <= 1; // x is a flip flop
q = input + 3; // q is a wire
if (condition)
q = q + 1;
if (other_condition)
x <= q;
end
This Verilog has perfectly defined behavior, but many ASIC designers can't
deal with it because of their experience with buggy tools (no mixed
block/unblocking assigns, no non-blocking assignments to the same register).
But these same designers are perfectly willing to use full_case and
parallel_case, which absolutely can cause synthesis/simulation mismatch.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 99868Yes the networking, communications, and DSP industries are thouroughly into the simple idea of timesharing, latency hiding etc and thats where I have been since leaving Inmos 20yrs ago. I also use those SRL16s to keep 4 sets of instruction fetch state over 8 clocks so that variable length opcodes can interleave without confusion. Without those, I'd be looking at 50% more LUTs per PE. As a Transputer person I want as many threads as possible for a thread pool, and these can then be effectively allocated on demand to the concurrent language threads. Of course for idle threads, I would push all threads onto busy PEs and shut down fully idle PEs, so power consumption follows work done. In the Niagara case, the goals are different, continuous threaded server loads. One thing I did realize is that the after doing all the MTA, MMU work, any old instruction set could be used even that damned x86 but since this is an FPGA design, its still better to tune for that and go KISS at speed. Its really a question of trading the single threaded Memory Wall problem for a Thread Wall problem. A problem for single threaded C guys, not so for the CSP people out there. Amdahls law has done more to set back parallel computing than who knows what, if its serial, then its serial, but there usually room to mix seq & par at many levels. Even if a task has 2 or 3 threads, MTA still comes out ahead on hardware cost. The paper I gave on this Transputer design at CPA2005 last sep, is finally available at wotug.org for anyone thats interested. Regards John Jakson PS Perhaps oneday somebody out there could make a nano CC size FPGA card but with some RLDRAM on it for a TRAM replacement.Article: 99869
Derek I am sure you would get better response in c.a.fpga. JohnArticle: 99870
Marco, We just designed a board that does just what you've described above. We have a signal going in to CCLK, which is also tied to a GPIO for use after configuration. It's stated in the datasheet that all inputs to CCLK after configuration are ignored, so that's not a problem. However I wouldn't assume that the GPIO is Hi-Z during during configuration. It depends on what you've done with the HSWAP_EN pin. We have that pin tied to GND which gives all of the GPIO weak pullups during configuration. This has not been a problem for us, so having external logic is not necessary. We are using parallel slave config mode. After configuration D0-D7 are used for the normal DSP data bus. Another thing to keep in mind: What is the signal voltage of your DSP? If it's not 2.5V, I would recommend having a look at this app not from Xilinx. http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=20477 Hope this helps. DaleArticle: 99871
Hello All, I am looking for a time efficient means to add USB capability to a Virtex-4 LX80. After looking around it seems that there are several third party solutions that require minimal number of interface I/Os (a byte wide data interface and a three wire serial control interface). However, I thought it would be a good idea to see if anyone with experience might suggest parts to avoid and parts that are recommended. Ideally what I would like to find is a part that requires less than about 20 FPGA I/Os to interface to and provides example driver source implementing a transfer of a single block of continously addressed memory. Thanks for any suggestions, BrendanArticle: 99872
Hi Falk, No problem, I can (will) use a 40.96MHz oscilator. And I'm using a SPARTAN3E, so the minimum clock is lower than for the SPARTAN3. I'm not sure if changing the Phase Shifter value "on the fly" will generate any disturbance at the output. I need to learn more about the DCM. Luiz CarlosArticle: 99873
USB 2.0 at 480 Mbps? 12 Mb/s? The PLX NetChip 2272 is an okay device for 480 Mbps though I dislike the asynchronous interface. I don't know if they have driver source available. http://www.plxtech.com/products/NET2000/default.asp I'd love to see a better option! "Brendan Illingworth" <billingworth@furaxa.com> wrote in message news:6tSdnV0slP-AkLHZRVn-rA@comcast.com... > Hello All, > > I am looking for a time efficient means to add USB capability to a > Virtex-4 LX80. After looking around it seems that there are several > third party solutions that require minimal number of interface I/Os (a > byte wide data interface and a three wire serial control interface). > However, I thought it would be a good idea to see if anyone with > experience might suggest parts to avoid and parts that are recommended. > Ideally what I would like to find is a part that requires less than about > 20 FPGA I/Os to interface to and provides example driver source > implementing a transfer of a single block of continously addressed memory. > > Thanks for any suggestions, > BrendanArticle: 99874
Hi considering me a novice. I have a very basic question. How can i connect multiple user IPs to a shared memory on FPGA. I am using Xilinx Virtex 4 FX FPGA and want to have a common memory place on chip where i can save all the signal comming from out side. This common place will also be used to share the output signal between the custom IP. I am planning to use BRAM for this purpose but since BRAM is dual port so i can have only two of the IP attached to it at any time. Please advice me since this issue is halting my design process. I also want to attach the processor to that shared memory so it can also share the signals with rest of user logic residing on FPGA. I am using on chip processor PowerPC405. Thanks Faraz
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