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
If you want to drive real bipolar TTL from a 3.3-V Vcco FPGA, just do it. No problem! No need for anything special. TTL treats any input >2.0 V as logic High (ever since TI issued this standard >40 years ago.) And the FPGA will generate a High signal close to 3.3 V. So you have plenty of noise immunity. Peter Alfke, Xilinx Applications aiiadict@gmail.com wrote: > >What FPGA? > > xilinx xc3s200 > > >What I/O supply voltage? > > 3.3v > > >How fast? > > a bit faster than 1 MHz > > >For others you may want to use special level translators or perhaps 3.3 > >volt buffers with 5v compatible I/O. > > Anybody have links to level translator components, or a 3.3v > buffer with 5v i/o? > > >Also, what logic family are you using on the 5v side - TTL > > TTL > > RichArticle: 97901
nezhate wrote: > Hi all, I want to use a small cricuit (written in verilog and was > designed using ISE 3) in an other project using ISE 8.1. the problem is > that under ISE 3 the circuit worked perfectly, and under ISE 8.1 the is > an error. why this occur ? Was the error in the operation of the circuit or in synthesizing the circuit. I've noticed that in 8.1i leaving output ports undriven results in an error when you get to BitGen, while in 6.1i and earlier these nets were just ripped out of the design in mapping.Article: 97902
Antti, Is it using TRI-MAC in V4FX? Thanks, /Mikhail "Antti" <Antti.Lukats@xilant.com> wrote in message news:1141208219.456883.178820@j33g2000cwa.googlegroups.com... > Ivan, > > I posted the full link twice - sorry you did not get it from my first > posting. Info on Paul's website says tested on V2Pro only - as of > today I can confirm that it works completly 'out of the box' on V4FX > also inclusive ehternet. No issues. Just build load and run. > > I had not tested networking yesterday, actually its a board where > ethernet has not been tester before at all, I only had the UCF file > setup, and when I booted ppclinux, well even network worked, I > only had to ping :) > > Antti >Article: 97903
>If you want to drive real bipolar >TTL from a 3.3-V Vcco FPGA, just do >it. No problem! ok, I can drive a TTL with an FPGA I/O pin, can I drive an FPGA pin with TTL? will 5v damage a 3.3v input on the FPGA? RichArticle: 97904
"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag news:46mav0Fbvb5uU1@individual.net... > Antti, > > Is it using TRI-MAC in V4FX? > > > Thanks, > /Mikhail > no, I just used PLB_ethernet not TEMAC, hm I dont know if the linux drivers are all available, hm would be nice of course,! AnttiArticle: 97905
Gabor wrote: > nezhate wrote: > >>Hi all, I want to use a small cricuit (written in verilog and was >>designed using ISE 3) in an other project using ISE 8.1. the problem is >>that under ISE 3 the circuit worked perfectly, and under ISE 8.1 the is >>an error. why this occur ? > > > Was the error in the operation of the circuit or in synthesizing the > circuit. > > I've noticed that in 8.1i leaving output ports undriven results in an > error > when you get to BitGen, while in 6.1i and earlier these nets were just > ripped out of the design in mapping. Have you mentioned that to Xilinx ? - just in case their "extensive regression testing" missed this. Sounds like yet another oops, that needs fixing... -jgArticle: 97906
I pass the input pulses through a shift register. For example, the
verilog equivalent is as follows
always @(posedge clk3 or negedge reset_n)
begin
if(~reset_n)
begin
delay_reg[0:29] <= 30'h000000;
end
else
begin
delay_reg[0:29] <= {video_in, delay_reg[0:28]};
end
end
assign delayed_video = delay_reg1[25];
So, the input pulses are delayed by 26 clock cycles.
Hope this makes things a little clear
Article: 97907
morpheus wrote:
> I pass the input pulses through a shift register. For example, the
> verilog equivalent is as follows
> always @(posedge clk3 or negedge reset_n)
> begin
> if(~reset_n)
> begin
> delay_reg[0:29] <= 30'h000000;
> end
> else
> begin
> delay_reg[0:29] <= {video_in, delay_reg[0:28]};
> end
> end
> assign delayed_video = delay_reg1[25];
> So, the input pulses are delayed by 26 clock cycles.
> Hope this makes things a little clear
In your simulator, look at the timing of the video_in input relative to
the sampling clock. I expect that the front edge and back edge of your
first pulse are on opposite sides of the rising edge of clk3 in your
simulation testbench resulting in a pulse width that's one clk3 period
different than what you expect. Your output pulse widths in an
asynchronous system will be the original pulse width +/-2 clk3 periods.
Why 2? If your pulse width is n clk3 periods and you sample right at
the edge of knowing which period the sample belongs in, both the front
and back edges have +/- 1 clk3 period of uncertainty.
Article: 97908XAPP709 states that a 200-MHz DDR SDRAM can be built using MIG coregen, however, when I run mig006_rel6 ISE7.1.04, I don't see V4s on the drop down selector. What's the story? BradArticle: 97909
Thanks John, you were right, in my stimulus, the video_in pulses (that is an input) were too close to the clk3 clock edge, however I have another question about this, in my design since i am using clk3 to clock video_in(asynchronous signal) into a shift reg, is a 2-stage synchronizer enough to reduce the effect of metastability on this signal?Article: 97910
If your shift register is implemented as registers instead of SRLs, metastability is taken care of for you. If you are using SRLs, the only caveat is that an intermediate level may be preserved as "uncertain" as it propagates through the SRL; the metastability just moves to the output side of the SRL. So... 2 registers is safest on the input but you could just as easily have those two on the output side of the SRL. Routing distances between 2 synchronizing registers should be given ~2ns slack to provide "exceptional" immunity rather than just "excellent." Things are so much cleaner these days!Article: 97911
Even an SRL does not propagate metastable levels. There is enough gain in each latch to eliminate metastable level in the second latch. The difference between SRLs and "normal" shift registers is that the SRLs use short-time capacitive storage between adjacent latches, while conventional shift registers use a master latch followed by a slave latch. There is a difference between logic uncertainty caused by metastability (which will propagate through any shift register or other sequential logic) and the physically "half-way" level, which does not survive more than one stage. Simulators propgate the X, but that is symbolic. Real flip-flops stay metastable only for up to a few nanoseconds. (Theoretically there is no upper limit, but in our limited lifetime any delay more than a few ns is so improbable that it is statistically insignificant). If you want to play it real safe, make that 10 ns. Peter Alfke, Xilinx Applications.Article: 97912
Hi, If your purpose is to just run "experiments on partial reconfig" than fabric may be ok. But in order to achieve any kind of reasonable speed it would be much better to build your 32x32 or 64x64 multipliers out of the 18x18 Multipliers available in the DSP48. The DSP48 has built in 17 bit shifts on PCIN that allow larger multipliers to be built by using several cascaded DSP48 slices. It seems from your email that you are trying to reuse the multiplier resource. I don't think you need to put the multiplier in the fabric to do that. It would be better to implement the multiplier in the DSP48s and just reprogram the connections to the multiplier resource. You could also just use a mux to share the resource at different points in time (The DSP48 can also function as a large bus mux). Even if you did want to move the multiplier all around the chip - its going to cost you a lot of slices (not to mention power) to implement a soft 64x64 multiply. I am not sure if it will be worth it even after Booth Encoding it. If you switch to an V4 SX chip then there will be several DSP48 columns allowing you to move your multiplier around to different parts of the chip. I am not sure about the specific RPM limitation that you have run into. With the DSP48 cascades - you can connect BCIN/BCOUT PCIN/PCOUT between DSP48 slices that you want placed next to each other. The cascade connections will force the tools to use adjacent DSP48 slices - so this is a quick way of constraining the placement of DSP48 slices in your design. Hope that helps, - Vic Love Singhal wrote: > Hi, > Thanks for replying. > I want to design 32 bit to 64 bit multipliers, so I can not use just > one 18x18 bit XtremeDSP slice. > > In my experiments, I am looking at how the shape of multipliers affect > their partial reconfiguration. This is when we do difference based > partial reconfiguration of the multiplier. If these multipliers do not > mix with other components and routing remains same, then when they are > reconfigured to new multiplier of same shape, lots of reconfiguration > bits can be saved. > > Dsp slices based multiplier will be location-constrained which I do not > want, as I want the multiplier to be placed anywhere in the area. > > I know that ISE 8.1 is now supporting module-based partial > reconfiguration using PlanAhead 8.1. But I am looking at saving the > reconfiguration bits inside the PRM part (which may internally consists > of multipliers and other components) of the design using > difference-based scheme. > > Hence, I need to specify to Xilinx floorplanner to not to mix the logic > of multiplier with other logic. Is there a way to specify such > constraint in UCF file without explicitly specifying location > constraints? > For getting similar shapes of multiplier, I wanted to specify RPM > constraints for the multipliers but I could not do it for Virtex 4. So > I was curious if this is a known limitation. > > Thanks, > Love Singhal > http://www.ics.uci.edu/~lsinghal >Article: 97913
aiiadict@gmail.com wrote: >>If you want to drive real bipolar >>TTL from a 3.3-V Vcco FPGA, just do >>it. No problem! > > > ok, I can drive a TTL with an FPGA I/O pin, > can I drive an FPGA pin with TTL? will 5v > damage a 3.3v input on the FPGA? Google "TI level Translator" Click first hit, Click again, and you are at http://focus.ti.com/logic/docs/generalcontent.tsp?templateId=5985&navigationId=11408&path=templatedata/cm/general/data/trans_splitrail Now, simply select the widths/voltages that suit. -jgArticle: 97914
I'd go for SPI for loading a DAC under FPGA control. It is simple enough to do with minimal logic. You do not need the sophistication of I2C. On the subject of I2C master hardware, IMHO they're a bit of a waste of resources. It is not much effort to bit-bash master behaviour. Why poll some I2C widget when you can simply poll the I2C lines. I2C slave hardware, now that is something worth doing.Article: 97915
>>> If there are any outputs that depend on less than 14 inputs push those >>> into BlockRAMs. >> There aren't; they all need more than 50. > Didn't you say something about 25 inputs? Sorry, I misread your statement. I thought you were talking about the OR matrix. If I use BRAMs for part of the AND matrix, it may slow things down, because I already need to register the output of the PLA, and this would make it take two cycles, or else require me to register all the product terms and move the OR matrix into the begining of the next cycle, adding to the combinatorial delay after the PLA. Or adding an out-of-phase clock for the BRAMs. I haven't yet studied the BDD stuff you suggested (CUDD), but it looks interesting. I also found a Java BDD package. I've already started hacking my Python PLA translator code to instantiate LUT primitives directly. It will be interesting to see whether P&R can do a good job on the result, or whether I'll have to come up with my own placement algorithm and use RLOCs. If my approach is successful, I'll publish the Python code in case it might be of use to anyone else with a similar problem. EricArticle: 97916
Jim Granville wrote: > Sounds interesting. Can you keep notes on the FPGA tools handling > of the various assistance levels, and report back when you have > it working ? I should have kept better notes on my attempts so far, which mostly amounted to fiddling with combinations of use of 'keep' attributes on the product terms, disabling USE_CARRY_CHAIN on the product terms and sums, whether to use timing-driven mapping, and the mapping and P&R effort levels. But so far no combination I tried gave better results than simply not using any attributes and running the tools with the default settings. If I throw in the attributes, the process takes up to ten hours to run, versus less than an hour without, so I haven't been able to try all permutations. But I've pretty much convinced myself that trying to make Foundation do a better job on the PLA through the use of attributes is a lost cause. I suppose to some extent I'm impressed that Foundation did as good a job as it did at the default settings, since I'm obviously doing something that the tools weren't really optimized for. > - and if you are doing AND and OR arrays separately, > then the CPLD XC2 flow I suggested would make another good > comparison. - ie compare your PLA optimizer with theirs ... I'll give it a try.Article: 97917
Kolja Sulimma wrote: > (using '-' not 'X') Oops, that's what I meant. Using '-' in a comparison works for synthesis, but not simulation. Now that I'm looking at it again, it looks like using std_match instead of the '=' operator would do what I want.Article: 97918
"nezhate" <mazouz.nezhate@gmail.com> writes:
> Hi all, I want to use a small cricuit (written in verilog and was
> designed using ISE 3) in an other project using ISE 8.1. the problem is
> that under ISE 3 the circuit worked perfectly, and under ISE 8.1 the is
> an error. why this occur ?
Probably because you're not rubbing together a regurgitative purwell and
a supramitive wennelsprock.
You might get better results after reading:
http://www.catb.org/~esr/faqs/smart-questions.html
Article: 97919Peter Alfke wrote: > The difference between SRLs and "normal" shift registers is that the SRLs > use short-time capacitive storage between adjacent latches, Doesn't this impose a maximum time for the clock to be in one state, as compared to a fully static approach?Article: 97920
Thanks for the clarification, Peter. Austin lead some of us here (me at least) to believe that the SRL might effectively preserve the intermediate level within the shift operation, pushing the metastability issue to the other side of the SRL. It's good to know they can eliminate sampling uncertainty in a simple, unconstrained SRL delay chain.Article: 97921
Not externally, but inside the SRL there is (I think) a clock differentiator. The idea is to put a low-pass filter between adjacent latches, and make the transfer pulse so short, that the transfer is only of the old, stable dta, not of the just arriving data. That avoids any race condition. The conventional master-slave flip-flop uses a more brute-force approach that requires two latches. The "low-pass filter, clock differentator" approach was popular 50 years ago, when discrete transistors were expensive, and resistors and capacitors were cheap. Peter Alfke, Xilinx ApplicationsArticle: 97922
Well, there is always the inherent sampling time uncertainty of one period of the asynchronous clock. I would reduce that by using a really fast clock, like 200 MHz+. Peter AlfkeArticle: 97923
The Virtex4 hardware supports partial reconfiguration and includes a lot of special hooks intended to increase the flexibility of usage of Partial Reconfig. Unfortunately the tools haven't quite caught up yet. This should improve with the new Plan Ahead 8.1 and future Software releases. Some applications like Software Defined Radio and Reconfigurable Computing are driving this. If you run into a problem please call the hotline or file a CR. If Partial Reconfig is important to you - let your local FAE know. That way in the future the software and tool support for Partial Reconfiguration will get the priority it deserves. - Vic Javier Castillo wrote: > Of course it works. Self-Reconfiguration on Virtex2,Spartan2 and > Spartan3 works fine. I said that Partial Reconfiguration on Virtex4 > using ISE doesnt work. I dont know if using PlanAhead it works. > > We have made many experiments and using Virtex4 during the final > assembly phase it fails due to problem with the disabled DCMs, and > many global logic that appears during this phase. That global logic > goes from TIE elements to CE inputs of the registers inside the > slices. For smal designs we have route it manually and we've got some > simple design of PR on Virtex4, but for larger designs is imposible to > route that logic. Appart for it there are a problem about using > Virtex4 block rams in modular design, I reported it, and it supposed > to be solved in a IP update for ISE8.1. I havent test it yet. > > Yesterday, when I downloaded SP2 for ISE8.1 I tested again the designs > and the problem of the global logic and unconnected DCMs havent > disappear. > > Regards > > Javier > > On 14 Feb 2006 14:16:00 -0800, "Peter Alfke" <peter@xilinx.com> wrote: > > >>I recommend reading the article below: >> >>http://www.fpgajournal.com/articles_2006/20060207_cray.htm >> >>Apparently RC works... >>Peter AlfkeArticle: 97924
On Wed, 01 Mar 2006 23:20:43 GMT, "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote: >I'd go for SPI for loading a DAC under FPGA control. >It is simple enough to do with minimal logic. > >You do not need the sophistication of I2C. > >On the subject of I2C master hardware, IMHO they're a bit of a waste of >resources. It is not much effort to bit-bash master behaviour. Why poll some >I2C widget when you can simply poll the I2C lines. > >I2C slave hardware, now that is something worth doing. The OP mentioned "motor control" so I assume that latency matters. This might rule out the use of bit-bashing. Regards, Allan
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